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CHAPTER  1 
INTRODUCTION 

1. 1 Summary  of  Research 

1. 1. 1 Coal  and  Purpose  of  Research 

The  ultimate  objective  of  the  research  reported  in  this 
dissertation  is  the  automation  of  the  software  development  process. 
The  literature  on  software  development  of  the  past  several  years  (see 
literature  survey  in  Chapter  2)  has  recognized  the  unlikelihood  of 
continued  building  of  large  complex  software  systems  by  the 
conventional  manual  methods  because  of  rising  software  development 
costs  and  demand  on  the  one  hand  and  the  shortage  of  sufficient 
trained  personnel  on  the  other.  This  research  and  that  of  others 
(surveyed  in  Chapter  2)  are  demonstrating  the  feasibility  of  reducing 
the  costs  of  software  development  by  utilizing  the  computer  itself  to 
produce  industrial  software  systems  automatically  based  on  functional 
specifications  from  the  business  or  management  specialist.  The  long 
term  objective  of  the  research  area  reported  here  is  to  eliminate  the 
computer-trained  personnel  involved  in  the  physical  system  design  of 
the  information  processing  system,  the  computer  program  designer,  and 
the  coder  as  middle  men  between  the  non-computer  trained  business 
specialist  who  can  specify  the  functional  automation  requirements 
formally  and  the  desired  operational  application  software  system.  The 
direction  of  such  research  is  to  make  computer  programming  not  only 
much  easier  and  less  costly  and  reduce  the  dependence  on  computer 
programmers  in  software  development,  but  ultimately  to  eliminate  the 
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physical  system  designer,  the  application  programmer,  and  coder  by 
automatically  producing  computer  programs  for  the  business  or 
management  specialist  on  demand. 

Toward  this  objective,  the  immediate  goal  of  this  dissertation 
has  been  the  development  of 

(1)  a non-procedural  Module  Specification  Language  (MODEL)  in 
which  an  analyst  specifies  a functional  module  of  an 
application  system;  and 

(2)  a software  system  that  automates  a significant  portion  of 
the  software  development  process;  namely,  the  program  module 
design,  coding,  and  debugging  phases  of  a large  class  of 
conventional  data  processing  programs  to  be  ('escribed. 

In  order  to  pinpoint  the  area  of  automation  covered  by  this  research, 
the  following  discussion  first  delineates  the  stages  of  the 
conventional  software  development  process  of  a typical  software 
development  project.  Although  the  delineation  of  these  stages  has  been 
viewed  differently  in  the  literature  (surveyed  in  Chapter  2),  they  are 
generally  as  follows: 

(1)  Determination  and  Statement  of  Overall  Problem  P%equirements. 

(2)  Analysis  of  Problem  Requirements  and  Production  of  System 
Functional  Specifications  which  describe  the  information  that  are 
input  to  and  output  from  the  envisioned  system  as  a whole. 

(3)  System  Physical  Design,  which  includes  identification  and 
specification  of  component  program  modules,  their  individual  inputs 
and  outputs,  and  evaluation  and  selection  from  alternative  file 


structures  (the  term  "program  module"  here  is  used  loosely  here  to 
refer  to  a functional  sub-component  of  the  system). 

(4)  Program  module  detailed  design,  conventionally  by  such  means  as 
program  flowcharts. 

(5)  Program  module  programming,  coding,  and  debugging,  usually  in  a 
high-level  programming  language  which  in  turn  is  compiled  into  a 
machine  language  program. 

(6)  Integration,  Operation,  and  Maintenance 

Documentation  of  the  system  is  a process  parallel  to  all  stages 
above.  Each  one  of  the  above  stages  in  the  software  development 
process  depends  upon  the  previous  one  above  it  and  the  stages  utilize 
specialists  in  management,  business,  information  systems  analysis, 
design  and  programming. 

As  indicated,  future  demand  and  costs  of  analysis,  design,  and 
programming,  will  necessitate  the  automation  of  several  of  these 
phases.  Other  related  research  projects  and  literature  have  provided 
system  development  tools  and  have  made  Inroads  into  the  partial 
automation  of  some  of  these  software  development  processes.  These 
include  the  various  automated  aids  to  the  system  analyst.  Software 
development  automation  to  date,  however,  has  been  primarily  in  the 
analysis  and  design  phases,  and  to  date  there  has  been  no  general- 
purpose  and  application-independent  automatic  system  that  produces 
complete  programs  from  non-procedural  functional  specifications. 
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An  initial  goal  of  this  research  was  the  development  of  the 
Module  Description  Language  (MODEL),  a very  high  level  and  purely  non- 
procedural language  in  which  a business  systems  analyst  could  describe 
the  functional  modules  of  a desired  application  information  system. 

More  importantly,  the  goal  of  this  research  is  the  automation  of 
stages  4 and  5 above,  the  program  design,  coding,  and  debugging  phases 
of  software  development,  by  designing  a software  system  to  process 
MODEL  specifications  and  produce  desired  programs.  The  MODEL  user 
could  utilize  the  MODEL  language  and  Processor  in  developing  an 
application  system,  by  writing  a formal  MODEL  specification  for  each 
of  the  modules  in  the  application  system  after  the  system  analysis  and 
design  phases  above  it  are  completed  by  some  other  process.  These 
descriptions  would  then  be  submitted  to  the  MODEL  Processor.  The  MODEL 
Processor  performs  the  program  writing  task  by  automatically 
completing  the  program  design  phase  and  generating  the  program,  thus 
replacing  the  coding,  debugging,  and  testing  phases  for  a wide  class 
of  data  processing  problems  described  below. 

The  class  of  programs  which  the  MODEL  Processor  would  be  capable 
of  generating  automatically  from  non-procedural  specifications  is  one 
whose  programs  have  traditionally  been  widely  developed  manually.  The 
majority  of  programs  traditionally  written  in  the  data  processing 
environment  can  be  generated  by  the  MODEL  Processor.  The  following  are 
some  of  the  features  by  which  this  class  of  programs  is  characterized. 
Within  each  of  the  programs  generated  by  MODEL,  there  is  a major  loop 
in  which  processing  Is  done  and  records  are  read  or  written  one  at  a 
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time.  Within  each  iteration  through  the  major  program  loop,  however, 
records  can  be  read  from  any  number  of  files,  routine  processing 
functions  can  be  invoked,  inner  iterations  through  repeating  items 
take  place,  data  is  moved  to  output  areas,  records  are  written,  etc. 
The  programs  generated  by  MODEL  process  one  record  at  a time  but  can 
preserve  information  (such  as  totals)  across  records  by  use  of 
functions.  This  class  encompasses  so-called  "Transaction  Processing" 
programs  that  are  widely  written.  The  programs  generated  by  MODEL  can 
process  data  from  any  number  of  input  files  and  produce  any  number  of 
output  files,  whose  file  organizations  are  either  sequential  or 
indexed  sequential.  There  are  programs  currently  outside  the  realm  of 
this  class,  but  the  techniques  described  in  this  dissertation  could 
and  are  being  expanded  to  other  areas.  Other  capabilities  and 
restrictions  of  MODEL  can  be  found  in  Chapter  3. 

1.1.2  Overview  of  the  Non-procedural  Language:  MODEL 

The  MODEL  language  allows  the  specifier  to  describe  the  desired 
program  nodule  by  a set  of  statements  describing  existing  (or 
"source")  data,  desired  (or  "target")  data,  and  a set  of  statements 
called  "assertions"  which  describe  various  types  of  data  inter- 
relationships. The  use  and  components  of  the  MODEL  language 
specification  are  explained  in  detail  in  Chapter  3. 
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Some  of  the  novel  features  that  were  incorporated  into  the 
language  design  are  summarized  here.  The  most  apparent  new  feature  of 
MODEL  when  compared  to  programming  languages  or  to  connand  languages 
of  data  base  management  systems  is  its  non-procedural  nature.  The 
MODEL  language  is  designed  to  be  as  close  to  non-procedural  as 
possible  in  several  respects.  All  statements  are  declarative  or 
descriptive  as  opposed  to  imperative.  The  statements  describe  only 
data  or  data  relationships  to  other  data.  The  procedural  detail  of 
programming  languages  (with  statements  such  as  READ,  URITE,  MOVE, 
OPEN,  CLOSE,  etc.)  is  not  in  the  MODEL  language,  since  actions  are 
deduced  by  the  Processor.  Furthermore,  the  statements  consist  of 
independent  descriptions  and  can  be  submitted  in  any  order.  Therefore 
the  specification  can  be  built  modularly  with  the  statements  added  in 
independent  stages  and  in  any  order.  There  are  no  control  structures 
connecting  them,  since  the  sequencing  and  control  logic  code  is 
produced  automatically  by  the  Processor,  finally,  there  is  a total 
absence  of  computer  programming  terminology  and  concepts.  There  is  no 
reference  to  sequences  of  operations,  control  code,  input  and  output 
commands,  counting,  data  movement,  memory,  computer  implementation,  or 
any  other  processes. 

Another  feature  of  the  MODEL  language  is  its  intended  use  for 
automatic  generation  of  the  application  programs  by  the  Processor  into 
a high-level  compiler  language,  namely  PL/1,  rather  than  into  a 
particular  machine  language.  This  promotes  machine  independence  and 
transferability. 
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MODEL  furthermore  is  donain/application  independent  since  it 
deals  solely  with  information  and  information  relationships.  Since  the 
MODEL  Processor  has  only  computer  programming  knowledge  (i.e.  a 
"model"  of  programming),  it  should  be  applicable  to  a broad  spectrum 
of  applications. 

A final  concept  of  MODEL  is  a potential  capability  to  store, 
control,  and  share  centrally-maintained  data  descriptions  and  a method 
to  provide  data  and  program  independence  without  resorting  to  the  more 
common  but  less  efficient  method  of  execution-time  binding  of  a data 
description  to  the  generated  program.  The  sharing  of  a centrally- 
maintained  data  description  would  be  especially  useful  in  a shared 
data  base  environment.  This  feature  is  described  conceptually  further 
in  Chapter  3,  but  is  not  included  as  part  of  the  Processor  described 
in  Chapter  4.  It  also  suggests  a capability  of  automatic  monitoring  of 
changes  to  the  data  base  description  and  automatic  invocation  of  the 
MODEL  Processor  itself  by  a monitor  to  regenerate  affected  modules. 

1.1.3  Overview  of  the  MODEL  Processor 

Chapter  4 describes  a software  system  called  the  MODEL  Processor, 
which  would  perform  the  program  writing  function.  The  MODEL  Processor 
has  been  designed  in  order  to  "model"  and  automate  the  program  module 
design,  coding,  and  debugging  phases  of  software  development  hased  on 
module  specifications  in  the  non-procedural  MODEL  language.  It 
presupposes  that  the  functions  of  the  desired  application  have  been 
described  to  the  extent  that  the  file,  inter-file,  and  intra-record 
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structures  have  been  described  and  that  the  system  has  been 
partitioned  into  functional  modules.  A module  is  then  formally 
described  and  specified  in  the  MODEL  language,  whose  statements  are 
then  submitted  to  the  MODEL  Processor.  The  MODEL  Processor,  in  turn, 
performs  the  following  tasks: 

(1)  analysis  of  the  specification  for  completeness  and  consistency; 

(2)  module  design,  which  includes  generating  a flowchart-like  sequence 
of  events  for  the  module;  and 

(3)  code  generation  function,  thus  replacing  the  tasks  of  the 
application  programmer/coder . 

Although  some  aspects  of  the  MODEL  Processor  have  some  similarity 
to  the  conventional  compiler  (e.g.  in  syntax  analysis  and  code- 
generation), it  differs  greatly  in  its  capability  to  process  a non- 
procedural specification  language  described  above,  in  its  internal 
model  of  data  processing  programming,  in  its  ability  to  detect  logical 
inconsistencies  and  incompleteness,  and  in  its  ability  to  make 
assumptions  about  the  program  logic.  These  capabilities  are  partially 
based  on  an  application  of  graph  theory.  Relationships  within  the 
specification  are  detected  by  the  MODEL  Processor  and  represented  in  a 
directed  graph,  which  is  used  as  a basis  for  analysis,  design  and  the 
program  generation  task. 

Another  important  function  of  the  MODEL  Processor  is  to  interact 
with  the  specifier  to  indicate  necessary  supplements  or  changes  to  the 
submitted  statements.  Messages  are  sent  to  the  user  to  indicate 
missing,  inconsistent,  or  ambiguous  statements  and,  when  possible. 


9 


suggestions  for  remedying  them. 

The  Processor  would  produce  a complete  PL/1  program  ready  for 
compilation,  and  various  reports  concerning  the  specification  and  the 
generated  program,  such  as  a listing  of  the  specification,  a cross- 
reference  report,  a f lov;chart-like  report  on  the  generated  program, 
and  a listing  and  summary  of  the  generated  program.  These  are 
regenerated  whenever  a specification  is  submitted. 

The  MODEL  Processor  goes  through  five  phases  in  its  analysis, 
design,  and  program  generation  tasks.  In  the  first  phase,  the  provided 
MODEL  Specification  is  analyzed  to  detect  syntactic  errors  and  some 
semantic  problems.  This  phase  of  the  Processor  is  itself  generated 
automatically  by  a meta-processor  called  a Syntax  Analysis  Program 
Generator.  This  phase  also  stores  the  statements  in  a simulated 
associative  memory  for  ease  in  later  search,  analysis,  and  processing 
and  prints  error  diagnostics  in  a report  for  the  user. 

In  the  second  phase,  the  MODEL  Processor  determines  precedence 
relationships  from  analysis  of  the  specification.  The  independent  and 
unordered  MODEL  statements  are  analyzed  for  precedence  relationships 
which  are  sometimes  determined  by  description  components,  and  other 
times  by  assumptions  based  on  a set  of  deductive  or  heuristic  rules. 
These  relationships  are  used  to  form  a precedence  graph  against  which 
the  completeness  and  correctness  of  the  specification  can  be  checked, 
and  reports  are  produced  for  the  user  indicating  the  data,  assertions, 
or  decisions  that  have  been  inadequately  described  and  displaying  the 
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Processor  assumptions  that  were  made  in  the  absence  of  Information 
provided  by  the  user. 

The  third  phase  of  the  Processor  determines  the  sequence  of 
execution  of  all  events  implied  by  the  specification,  using  precedence 
and  graph  theory  techniques,  and  thereby  determines  the  sequence  and 
control  logic  of  the  desired  module.  It  also  deals  with  scope  and 
iteration  analysis.  The  result  of  this  phase  is  a set  of  data 
structures  representing  the  desired  sequence  of  processes  and  flow  of 
events,  sequenced  and  ranked  in  their  order  of  execution.  Thus,  the 
output  of  this  phase  is  a table  that  is  similar  to  a program  flowchart 
of  the  desired  module,  and  is  subsequently  used  to  produce  a 
flowchart-like  report  and  the  program. 

The  fourth  phase  is  code-generation  which  entails  insertion  of 
code  into  the  entries  of  the  flowchart  to  produce  the  program  in  a 
high-level  language,  PL/1,  ready  for  compilation  and  execution.  Code 
is  produced  in  two  steps  for  purposes  of  modularity  and  independence 
of  the  target  language.  The  first  step  produces  a language-independent 
version  of  the  flowchart-entries,  while  this  second  step  produces  code 
in  the  PL/1  programming  language.  Code  is  generated  for  input /output 
commands,  for  procedures  and  their  invocations,  for  program  iterations 
and  other  control  structures  that  are  necessary,  and  for  declarations 
for  object  program  data  structures  and  variables.  A listing  of  the 
generated  program  as  well  as  the  flowchart-like  report  is  produced. 


11 


Finally,  the  automatically  produced  PL/1  program  nodule  is  ready 
for  compilation  by  the  PL/1  optimizing  compiler,  which  carries  out 
program  compilation  and  optimization  of  code  on  the  machine-language 
level.  Integration  of  the  program  into  the  system  and  its  subsequent 
execution  can  then  take  place  by  traditional  means. 

1.2  Summary  of  Contributions 

The  importance  of  this  dissertation  lies  In  several  areas.  The 
development  of  a non-procedural  language  for  defining  information 
systems  is  useful  in  itself  to  express  a specification  to  a 
programmer.  The  formal  language  imposes  a discipline  on  the  specifier 
of  the  application  system  and  allows  the  problem  to  be  expressed 
descriptively  and  logically  rather  than  procedurally  and  physically. 

The  primary  result  of  this  research  is  the  development  of  a new 
and  automated  approach  to  producing  software,  an  approach  which  offers 
a viahlc  alternative  to  conventional  manual,  software  development,  and 
which  should  reduce  the  cost  of  its  development. 

A major  contribution  of  this  research  is  the  development  of  a 
series  of  algorithms  which,  taken  as  a whole,  constitute  a Processor 
that  automatically  produces  programs  from  specifications  in  the  MODEL 
language.  The  MODF.L  Processor  demonstrates  a structured  design  and 
programming,  methodology  for  the  application  system. 
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Regarding  Implementation,  over  12,000  lines  of  Pl./l  code  have 
been  written  for  most  of  the  algorithms.  The  algorithms  are  given  in 
the  body  of  the  dissertation,  and  the  corresponding  FL/1  code  is  in 
the  appendix,  because  the  author  had  to  assume  a position  in  Septenber 
1975,  further  developmental  and  testing  work  has  been  left  for  the 
future;  nevertheless,  the  feasibility  of  the  automation  of  the 
Processor  is  already  evident. 

The  MODEL  Processor  is  an  example  of  a knowledge-based  system  in 
that  it  embodies  a formalized  knowledge  of  how  to  write  data 
processing  programs,  and  thus  replaces  the  application 
programmer /coder . As  shown  in  Chapter  4,  the  programming  philosophy 
formalized  in  the  Processor  docs  not  necessarily  pattern  that  of  the 
typical  human  data-proccsslng  programner.  The  Processor  accepts  a set 
of  unstructured  and  unordered  descriptions,  formulae,  assertions, 
rules,  etc.,  and  builds  a structure  around  it,  with  a flow,  control 
logic,  and  procedural  operations  not  explicit  in  the  descriptive 
specification. 

The  benefits  of  automating  the  design  and  generation  of  program 
modules  using  this  approach  can  be  seen  readily  in  its  effective 
utilization  of  manpower  and  machine.  By  imposing  a discipline  on  the 
program  nodule  deflner  and  allowing  him  to  concentrate  on  the  logical 
aspects  of  the  program,  fewer  errors  should  result  in  system  building. 
Automatic  checkout  of  the  specification  by  the  Processor  quickly  and 
accurately  pinpoints  many  ambiguities,  incompleteness,  or 
inconsistency  within  it.  As  confidence  would  be  gained  with  the 
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Processor  over  tine,  the  Processor  could  be  relied  on  to  detect 
problens  with  the  specification.  M0DE1,  requires  the  specifier  to 
provide  data  descriptions  and  to  express  arithmetic  and  logical 
relationships  inherent  in  the  problem,  but  relieves  him  from  all 
procedural,  physical,  computer-oriented,  sequencing,  input/output , 
control  logic,  and  "housekeeping"  problems  that  are  in  the  realm  of 
programming,  by  using  such  a Processor,  the  machine  can  design  and 
generate  the  program  modules  of  the  desired  application  system. 
Furthermore,  by  accepting  a machine-readable  specification,  and  by 
providing  feedback,  reports,  and  charts  (including  a flowchart-like 
report),  the  Processor  also  partially  automates  the  documentation 
process . 

Thus,  the  MODEL  system  is  a step  towards  eliminating  the 
application  programmer  and  effecting  a direct  communication  between 
the  system  specifier  and  the  machine.  It  is  therefore  a crucial  step 
in  the  automation  of  software  development,  with  immediate  potential 
for  saving  man-hours  and  cost  in  software  development. 

1.3  Organization  of  this  Dissertation 

Chapter  2 is  a summary  of  background  and  motivation  to  this 
research  and  a survey  of  related  literature  and  research.  It  reviews 
other  effort  and  research  in  the  automation  of  different  aspects  of 
software  development,  and  Is  especially  directed  towards  the  reader 


unfamiliar  with  this  area  of  research 
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Chapter 

3 describes 

the 

MODEL 

language  with  a more  elaborate 

overview 

of 

its  purpose 

and 

role 

in  software  development. 

i ts 

features , 

an 

example  of 

its 

use. 

and  a detailed  description 

and 

examples  of  the  KOPF.L  language  itself.  A formal  grammar  of  the 
language  is  also  provided.  Chapter  3 can  be  read  by  a user  as  a guide 
independent  of  the  other  chapters. 

Chapter  4 describes  the  design  of  the  MODEL  Processor,  including 
the  theoretical  background,  system  methodology,  algorithms,  and 
programming  techniques. 

Chapter  5 summarizes  the  conclusions  that  can  be  drawn  based  on 
this  research,  and  suggests  directions  for  further  research. 

An  appendix  is  provided  at  the  end  with  a sample  problem 
expressed  in  MODEL  and  its  corresponding  output  that  would  be  produced 
by  the  MODEL  Processor.  Also  included  in  an  appendix  is  the  source 
code  for  some  of  the  modules  of  the  system. 


CHAPTER  2 


Background,  Motivation,  and  Survey  of 
Related  Literature  and  Research 


2. 1.  Introduction 


The  motivation  for  this  research  arises  from  concerns  over  the 
rising  costs  of  software  development  and  the  forseen  difficulties  in 
continuing  to  build  complex  software  systems  by  the  conventional 
manual  methods.  This  concern  is  commonly  reiterated  in  the  literature 
of  recent  years  as  the  following  sample  of  quotations  demonstrates. 


Boehm  [ROE  73]  estimates  the  ratio  of  software  to  hardware  costs 

to  rise  to  10  to  1 by  1985  if  present  trends  continue  and  warns  that 

If  the  software-hardware  cost  ratio  appears  lopsided  now, 
consider  what  will  happen  in  the  years  ahead  as  hardware  gets 
cheaper  and  software  (people)  costs  go  up  and  up. 

Prywes  [PRY  74]  concurs  that 

'Jhile  improvements  in  hardware,  system  software  and 
programming  languages  continue  to  make  programming  more 
effective,  they  are  not  sufficient  to  compensate  for  the 
dramatic  increases  in  demand  for  software...  [and  an 

increased  programming  ] requirement  would  constitute  not  only 
a financial  obstacle  to  advances  in  use  of  computers,  but 
also  such  a labor  force  cannot  be  recruited  or  trained. 


In  proposing  the  automation  of  systems  building,  Teichroew 
[TEI  71]  points  out  that 

It  is  extremely  unlikely  that  it  will  be  possible  to  build 
the  number  of  systems  of  the  size  and  complexity  desired  by 
manual  methods  — there  will  not  be  enough  people. 
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The  sample  of  papers  referenced  above  [TRI  71,  PRY  74]  and  other 
studies  [KOS  74]  have  recognized  and  proposed  that  a solution  to  the 
systems  building  task  is  going  to  have  to  be  the  utilization  of  the 
computer  itself  in  the  software  systems  development  process.  That  is, 
there  is  a necessity  for  at  least  the  partial  automation  of  the 
software  development  process  in  order  to  cope  with  the  rising  software 
costs  and  shortage  of  sufficient  trained  personnel. 

2.2.  Improvements  to  the  Software  Development  Process 

Before  reviewing  efforts  that  have  been  made  and  are  continuing 
in  the  automation  of  the  various  phases  of  the  software  development 
process,  which  in  turn  gives  perspective  on  the  research  reported 
here,  the  following  discussion  first  reviews  other  attempts  that  have 
been  made  to  aid  and  harness  the  software  development  task. 

Recent  developments  in  software  development,  programming 
languages,  and  software  management  techniques  promise  to  improve  the 
productivity  and  quality  of  software  to  some  extent.  Much  attention 
has  been  given  in  recent  literature  to  "structured  programming" 
[DAH  72,  BAK  72b,  DON  73,  MIL  73],  "top-down  programming"  [MIL  71, 
MIL  73],  and  "chief-programmer-team"  effort  [BAK  72a,  ?>AK  72b, 
BAK  73].  These  form  an  inter-related  set  of  programming  techniques 
that  can  shorten  the  software  development  process  in  the 
implementation  phases.  These  include  imposing  a well-defined 
discipline  on  the  programmer,  restricting  and  simplifying  the  set  of 
control  structures  to  be  used  by  programmers,  modular  program  design 
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from  "top"  to  "bottom"  by  use  of  successive  refinement  of  detail, 
limiting  the  size  and  complexity  of  modules,  etc.  In  addition  to 
promoting  the  above,  writers  such  as  Roehm  [ROE  73]  also  suggest 
better  management  of  software  production  to  include  accepted 
procedures  such  as  thorough  organization,  setting  milestones,  early 
prototypes,  setting  contingency  plans,  making  good  test  plans, 
detailed  interface  specifications,  etc.  Although  these  suggestions  are 
useful  if  practiced  and  the  "stuctured"  developments  are  significant 
in  improving  software  production,  they  are,  as  seen  from  the  above 
comments,  by  no  means  a "cure-all"  and  are  not  likely  to  solve  the 
software  development  problem  in  the  long  run. 


The  use  of  general  application  packages  has  been  another  way  to 
reduce  the  cost  of  acquiring  a software  system  for  many  years.  These 
are  mostly  software  packages  consisting  of  general  programs  that  are 
oriented  towards  a specific  application  area,  and  which  are  then 
attempted  to  be  tailored  to  a specific  user's  needs.  Application 
packages  range  in  sophistication  from  those  for  which  the  user  only 
enters  data  values,  to  those  where  he  provides  parameter  values,  to 
those  where  he  selects  options  be  means  of  a checklist  or  questionaire 
(such  as  the  IRM  Customizer  for  the  System/3),  to  those  where  the  user 
has,  in  addition,  a command-language  to  select  certain  options.  A 
sophisticated  example  of  an  application  package  that  can  be  customized 
can  be  found  in  the  operations  management  area  [MAX  75].  Other 
examples  of  the  latter  packages  are  some  of  the  auditing  packages  for 
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extracting,  summarizing,  and  formatting  data  [APA  72,  UIL  72], 

The  primary  deficiency  of  application  packages  are  their 
limitations  due  to  lack  of  flexibility.  The  user  must  fit  his  solution 
into  a rigid  structure  of  the  pre-written  program.  Furthermore,  as  the 
user  requirements  increase,  there  arises  a need  for  special-purpose 
programming  which  requires  programming  skill.  The  requirement  to  have 
programming  skill  and  procedural  knowledge  is  also  involved  in 
applying  the  package  initially  and  in  inserting  needed  subroutines. 
Finally,  some  of  these  packages,  especially  those  that  are  in  the  form 
of  a library  of  generalized  parameterized  routines,  tend  to  be 
inefficient  in  execution. 

For  many  years,  application-independent  "generalized"  packages 
have  also  been  involved  in  some  aspects  of  software  from  input/output 
subroutines,  to  sort/merge  packages,  to  report  generators,  to  file 
maintenance  programs.  All  of  these  relieve  the  programmer  of  any 
application  from  details  which  are  well-understood.  These  application- 
independent  packages  (such  as  general  file-maintenance  and  report 
generation  packages)  and  even  those  that  are  pre-processors  to  a 
compilation  (e.g.  CP.APE  [GRA  72]  and  SCOFF  and  others  reviewed  in 
(AOA  72]),  have  inherent  limitations  and  cannot  be  considered  to  be 


automatic  generators  of  programs 
requirements  because  they  have  one 
deficiencies: 


that  can 
or  more 


meet  general  user 
of  the  following 
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(1)  They  are  tailored  to  a specific  class  of  applications, 

(2)  They  impose  a rigid  control  structure  inherent  to  the 
generated  progran, 

(3)  They  require  a procedural  knowledge  to  use,  or 

(A)  They  require  a knowledge  of  COBOL  or  other  language  for 
reasons  such  as  inserting  and  writing  subroutines. 

A greater  level  of  sophistication  has  been  reached  in  recent 
years  with  the  development  of  generalized  data  base  management  systems 
[COD  70,  COD  71a,  COD  71b,  PRY  f>6,  PPY  72].  These  systems  enable  the 
user  to  view  data  in  elaborate  logical  structures  by  mapping  them  into 
physical  representations,  relieve  their  users  of  much  of  the  details 
of  access  and  other  operations,  and  provide  for  greater  control  and 
independence  of  data,  among  other  services.  Data  base  management 
systems,  however,  still  require  their  users  to  have  programming  skill 
and  procedural  knowledge,  through  a conventional  programming  language 
host  system,  (e.g.  IMS),  or  through  an  independent  command  language 
(e.g.  ftARK  IV).  They  furthermore  are  often  difficult  to  use,  have 
great  limitations  imposed,  and  are  often  inefficient  and  costly  in 
execution.  In  spite  of  these  drawbacks,  their  current  development  is 
significant  in  data  organization,  access,  management,  and  control,  hut 
they  by  no  means  will  solve  the  requirement  for  programmers. 
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2.3.  Research  on  Autonation  of  the  Systens  Building  Process 


Only  in  the  last  few  years  has  there  been  a concerted  effort  to 
automate  systematically  the  systens  building  process.  The  ensuing 
discussion  reviews  the  contribution  and  efforts  of  various  projects, 
papers,  and  systens  in  automating  one  or  more  phases  of  the  software 
development  process.  For  discussion  purposes,  the  typical  software 
development  process  can  be  broken  into  the  following  steps  or  phases 
which  have  been  alluded  to  elsewhere  in  this  dissertation.  These 
divisions  are  similar  to  those  found  elsewhere  in  the  literature 
[COU  73,  TEI  71,  PRY  74]: 

(! ) determination  of  user  requirements; 

(2)  production  of  system  functional  specifications; 

(3)  system  physical  design: 

(a)  evaluation  and  selection  of  files  and  their 
organization ; 

(b)  decomposition  of  the  system  into  modules; 

(4)  program  design; 

(5)  coding,  debugging,  and  testing; 

(6)  operations  and  maintenance. 

The  systematic  automation  of  each  of  these  phases  has  been  proposed 
several  years  ago  [TEI  71]  in  a large-scale  research  project,  ISPOS 
(Information  Systems  Design  and  Optimization  System),  that  has  made 
progress  in  several  areas  surveyed  below.  The  potential  benefits  of 
automating  each  of  these  stages  have  been  subsequently  evaluated 
[PPvY  74,  TEM  72].  Prywes'  survey  [PRY  74]  estimates  the  percentage  of 
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cost  reduction  that  could  be  effected  by  the  automation  of  each  of 
these  phases,  and  suggests  possible  directions  that  such  automation 
night  take. 

The  least  amount  of  automation  progress  has  been  made  in 
determination  of  user  requirements  in  phase(l)  and  the  production  of 
system  functional  specifications  in  step  (2)  which  require  knowledge 
of  the  application  area  and  problem-solving  capabilities.  This  has  so 
far  been  automated  only  very  minimally  by  severely  limiting  the  scope 
of  the  problen  domain  in  application-specif ic  packages  cited  earlier. 
Such  packages  require  manual  programming  of  a model  of  the  application 
area  or  "problen  domain",  perform  a logical  as  well  as  physical 
design,  and  then  generate  a program  based  on  generalized  pre-stored 
programs. 

Balzer  [BAL  73]  in  an  AF PA -sponsored  project  defines  "automatic 
programning"  as  the  process  of  accepting  a problem  in  terms  of  a model 
of  the  domain,  obtaining  a solution  for  the  problem  in  terms  of  this 
model,  and  producing  an  efficient  computer  program  as  the  solution. 
Thus,  Palzer's  view  is  that  of  automating  the  entire  software 
development  process  without  any  recognition  of  the  division  of  phases 
above  that  actually  require  different  areas  and  levels  of  knowledge, 
l'e  further  suggests  that  it  will  he  possible  to  have  the  computer 
system  acquire  a model  of  the  problem  domain  through  an  interactive 
session  in  a natural  language.  Yet  success  with  such  an  approach  seems 
to  be  a long  way  off  and  will  not  be  realized  until  major  advances  are 
made  in  artificial  intelligence  and  problem  solving  techniques. 


Natural  language  processing  and  problen  solving  have  so  far  only  been 
successful  when  the  knowledge  base  of  the  problen  dona In  Is  so  snail 
as  to  be  entirely  representable  fornally  (see  [HEW  71,  WIN  73]).  As 
observed  in  [PRY  74] , the  possibility  that  the  conputer  systen  itself 
can  acquire  a nodel  of  the  problem  domain  through  an  interactive 
natural  language  session  requires  advances  beyond  the  current  state- 
of-the-art  automatic  problem-sol ving  methods  (as  surveyed  in 
[S11A  73]). 

Hore  progress  has  been  made  in  the  partial  automation  of  the 
middle  phases  of  software  development:  expressing  problen  statements 
formally,  automatically  analyzing  system  functional  specifications, 
and  producing  a physical  design.  These  are  described  below. 

After  the  overall  user  requirements  have  been  determined  in  phase 
(1),  a step  towards  further  automation  is  the  expression  of  those 
reauirements  in  a formal  language.  There  are  a number  of  so-called 
problem  statement  languages  for  expressing  system  functional 
specifications  formally  [TEI  72],  some  theoretical  and  some  more 
pragmatic.  The  importance  of  such  languages  was  recognized  at  least 
theoretically  quite  early  with  works  such  as  those  of  Young  and  Kent 
[YOU  58],  The  Problem  Statement  Language  (FSL)  of  the  ISDOS  project  so 
far  seems  to  be  the  most  complete  specification  language  to  express 
system  functional  specifications  formally  [TEI  72,  PER  73].  The  impact 
of  such  problem  statement  languages  has  been  shown  to  be  of  great 
benefit  [TEH  72]  in  aiding  the  software  development  effort  by  giving 
the  problem  definer  a formal  way  of  expressing  the  problem  without 
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having  to  specify  how  the  task  will  he  carried  out  and  by  putting  such 
specifications  into  a form  that  they  could  be  analyzed  automatically. 

Once  the  functional  specifications  have  heen  expressed  formally 
in  machine-readable  form,  a further  degree  of  automation  has  resulted 
by  automatically  checking  the  specifications  and  producing  some  of  the 
system  phyical  design.  The  1SD0S  project  [TEI  71]  and  Hunanaker 
[NUN  71]  to  name  two,  have  made  inroads  into  the  automatic  analysis  of 
problem  statement  languages  and  the  automatic  physical  design  and 
optimization  of  information  systems.  The  ISDOS  project  under  the 
direction  of  Professor  Teicbroew  [TEI  71,  TEM  72,  HEP  73]  has 
developed  a system  which  so  far  performs  analysis  of  functional 
specifications  expressed  in  a Problem  Statement  Language  at  the  system 
level  and  generates  numerous  reports  about  the  specification. 
Hunanaker's  work  [NUN  69,  HUH  71,  NUN  72a,  NUN  72b]  has  led  to  a 
system  which  can  perform  the  file  and  module  design  of  an  application 
system  with  sequential  files  by  evaluating  the  different  feasible 
designs  and  selecting  the  "best".  A more  general  automatic  file  and 
nodule  design  system  has  been  proposed  and  is  currently  being  pursued 
by  Gibb  [Cl  15  75]. 

llore  limited  aids  to  the  systems  analyst  have  actually  been 
available  previously  in  f orms-oriented  and  tabular  languages  (see  for 
example  [ADS  68,  TAG  68]).  In  fact,  a machine-readable  and  machine- 
checked  version  of  the  forms-oriented  Accurately  Defined  Systems 
(called  PSL/ADS  ) had  also  been  implemented  as  part  of  the  ISDOS 
project  [THA  71]  as  a predecessor  to  the  current  more  complete  PSL/II 
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[HF.R  73]. 

Other  efforts  on  automatic  physical  systems  design  (phase  3 
above)  have  resulted  in  a model  for  selection  of  file  organizations 
for  a simple  system  [SEV  72]  and  in  a system  for  the  automatic 
evaluation,  simulation,  and  selection  from  alternative  file 
organizations  [CAR  73].  Numerous  other  papers  have  been  written  which 
shed  light  on  the  automation  of  the  physical  design  process  through 
formal  nodels  and  structured  systems  development  techniques  (see,  for 
example,  [PAR  72,  SHE  74,  GRA  73]). 

The  contributions  of  the  above  systems  and  research  papers  have 
been  primarily  in  partially  automating  stages  (2)  and  (3)  above.  These 
systems  as  yet  are  not  involved  in  automating,  the  latter  stages; 
i.e.  they  do  not  generate  programs  based  on  previous  non-procedural 
specification,  analysis,  and  design.  These  efforts  have  enabled 
automatic  checking  of  system  functional  specifications  and  production 
of  some  of  the  system  physical  design  based  on  analytic  grouping 
decisions  or  simulation  techniques. 

The  research  reported  in  this  dissertation  helps  to  bridge  the 
automation  gap  by  attacking  the  automation  of  phases  4 and  5 above  -- 
the  program  design,  coding,  and  debugging  phase.  As  explained  in 
detail  in  Chapter  3,  MODEL  is  a language  for  describing  modules  of  an 
information  processing  system  which  has  previously  gone  through  phases 
1 through  3,  the  logical  and  physical  design  process,  and  an  important 
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feature  Is  its  non-procedural  nature.  Non-proceduralness  (discussed  in 
greater  detail  in  Chapter  3)  has  been  recognized  as  an  important 
feature  for  many  reasons  (YOU  65,  TCI  72,  PPO  74,  PRY  74],  such  as 
enabling  descriptive  statements  that  can  appear  in  arbitrary  order, 
relieving  the  user  from  sequential  and  detailed  steps,  etc.  The  MODEL 
language  has  facilities  to  describe  the  module  source  and  target 
files,  data  descriptions,  and  assertions  to  provide  data  inter- 
relationships. The  data  description  portion  of  the  language  is  similar 
to  data  description  languages  [COD  71b,  PUY  72,  SMI  71,  SIP.  73, 
MEF  74],  and  in  fact  is  an  extension  and  outgrowth  of  a data 
description  and  translation  project  of  which  the  author  was  a member 
[RAM  73,  RAM  74,  RIN  74]. 

The  MODCL  Processor,  discussed  in  Chapter  4,  has  the  task  of 
accepting  MODEL  specifications,  analyzing  and  checking  them,  and 
producing  executable  programs. 

There  are  other  efforts  currently  on-going  in  the  automation  of 
the  program  generation  phase  of  software  development,  but  which  vary 
in  orientation  and  approach.  Nunamaker  (in  a continuation  of  work 
begun  in  the  ISDOS  project  [BLO  73])  is  currently  pursuing  work  on 
automatic  generation  of  transaction-oriented  programs  for  Data  Base 
Task  Croup-type  data  base  management  systems  environments,  though  the 
language  seems  to  require  procedural  supplements  on  the  part  of  the 
user.  The  MODEL  approach  has  a greater  degree  of  non-proceduralness 
and  generates  a traditional  but  efficient  program  using  the  operating 
system's  access  methods. 
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The  automatic  program  design  and  coding  phase  is  apparently  also 
encompassed  in  the  automatic  programming  project  of  the  AFPA  sponsored 
Automatic  Programming  Croup  at  the  Massachusetts  Institute  of 
Technology.  Other  than  ISD05,  this  is  another  major  research  project 
whose  eventual  aim  is  the  total  automation  of  all  phases  of  the 
software  development  process  outlined  above,  and  it  incorporates  both 
application-dependent  knowledge  with  user  interaction  in  natural 
language  and  computer-dependent  knowledge.  From  preliminary 
indications  [MAP  74,  POT  74],  their  automatic  programming  system  seems 
to  require  procedural  knowledge,  is  more  theoretical,  and  is  not  as 
user-oriented  or  general  as  the  PSL/PSA  of  ISDOR  and  other  non- 
procedural approaches  such  as  the  research  reported  in  this 
dissertation. 

Another  automatic  program  generation  project  is  being  pursued  at 
the  University  of  Pennsylvania  in  the  area  of  automatic  testing 
systems  [PRY  75].  Some  of  the  code  written  by  this  author  for  MODEL  is 
being  used  in  the  implementation  of  that  project. 

From  the  above  survey,  it  is  clear  that  there  is  not  yet  one 
complete  system  that  automates  the  entire  software  development  process 
by  taking  system-level  functional  specifications  through  physical 
design  and  program  generation,  although  there  have  been  inroads  into 
many  of  the  steps.  The  research  reported  in  this  dissertation  is 
intended  to  supplement  the  above  group  in  its  contribution  towards  the 
automation  of  the  program  design  and  implementation  process. 


CHAPTER  3 


The  MODEL  Language 

3. 1 Introduction 

3.1.1  Overview  of  Purpose  and  Usage 

One  of  the  initial  goals  of  this  research  was  the  development  of 
the  Module  Description  Language  (MODEL),  a very  high  level  non- 
procedural language  in  which  a business  systems  analyst  could  describe 
a desired  application  information  system. 

Specifications  in  the  MODEL  language  would  be  submitted  to  the 
MODEL  Processor  which  would  for  the  most  part  automate  the  program 
design  and  implementation  process. 

Before  describing  the  nature  of  the  MODEL  language  and  its  "non- 
procedural" aspects,  this  section  first  turns  to  its  purpose  and  role. 
In  order  to  understand  the  role  of  the  MODEL  language  within  the 
conventional  software  development  process,  the  stages  of  software 
development  are  defined  below.  There  is  really  no  fine  line  between 
phases,  and  the  phases  do  overlap.  Similar  divisions  of  the  software 
development  process  can  be  found  in  other  literature 
[COU73, PF Y74.TFI 71 ] . The  following  delineation  of  the  software 
development  process  refers  to  Figure  3.1  (taken  from  [PRY74]).  A 
discussion  of  which  phases  of  the  software  development  process  the 
MODEL  language  and  Processor  automate  is  presented  after  the  following 
breakdown. 
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STAGES  IN  A SOFTWARE  DEVELOPMENT  PROJECT 
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(1 ) Determination  and  Statement  of  Overall  Problem  Requirements 

The  initial  phase  of  a large  software  development  project  is 
concerned  with  the  information  needs  of  management.  This  phase  is 
prompted  by  top  management  and  involves  personnel  with  expertise  in 
the  application  area.  The  result  of  this  phase  would  be  an  overall 
description  of  the  information  system  and  a preliminary  cost/benefit 
analysis. 

(2)  Analysis  of  Problem  Requirements  and  Production  of  System 
Functional  Specifications 

This  phase  involves  analyzing  the  overall  system  description.  It 
consists  of  describing  the  overall  information  flow  involving 
personnel,  communications,  manual  processes,  and  computers,  and 
defining  transac tions , documents,  reports,  and  other  information  in 
the  system.  In  this  step,  the  computer  is  viewed  as  one  big  black  box. 
The  functional  specif ications  produced  in  this  stage  describe  the 
information  and  transactions  that  go  in  one  end  of  the  system  and  all 
the  reports  and  information  that  come  out  of  the  system.  In  a well- 
managed  software  development  project,  the  specifications  will  be  as 
formal,  precise,  and  complete  as  possible. 
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(3)  System  Physical  Design 

The  system  design  phase  consists  of  several  activities.  One  is 
decomposing  the  desired  system  Into  logical  sub-units  or  modules. 
Another  Is  organizing  and  designing  the  aggregate  of  data  mentioned  In 
the  functional  specifications  Into  flies,  based  on  such  factors  as 
frequency  of  use,  location  of  use,  efficiency  considerations,  etc.  A 
third  activity  Is  selecting  the  files  in  and  out  of  each  module.  This 
phase  is  performed  by  computer  specialists,  including  analysts  and 
senior  programmers.  Each  identified  program  module  is  typically 
associated  with  a transaction,  an  updating  function,  or  a reporting 
function.  The  products  of  this  phase  are  the  file  structure 
specifications,  record  layouts,  system  flowcharts,  and  the  program 
module  logical  specifications  which  incorporate  the  system 
specifications  on  a per-module  basis. 

(4)  Program  Design 

The  program  design  phase  is  concerned  with  the  detailed  logic  of 
each  module  of  the  system.  It  involves  analysis  of  the  input  and 
output  data  of  the  module  and  analysis  of  the  specification  of 
information  relationships  and  algorithms  to  be  used  within  the  module. 
From  this  knowledge,  this  phase  has  to  enumerate  and  sequence  the 
events  to  take  place  in  the  module;  i.e.  the  design  of  the  sequence 
and  control  logic.  This  has  traditionally  been  written  in  the  form  of 
a program  flowchart  by  a programmer  or  programmer /analyst . 


This  is  the  final  implementation  phase  where  the  data  is 
declared,  the  processes  are  ordered,  and  input/output  statements  are 
included.  All  this  is  embedded  in  appropriate  control  structures,  and 
coded  by  programmers  in  a compiler  language  such  as  COBOL  or  PL/1. 
Debugging  and  testing  proceed  to  check  out  the  program. 

The  term  "program  module"  in  this  entire  discussion  refers  to  a 
logical  sub-unit  of  a larger  information  system,  such  as  the  "sale 
module"  or  "reorder  module"  of  a department  store  inventory  system. 
This  looser  use  of  the  term  "module"  may  not  necessarily  correspond  to 
that  in  literature  on  top-down  and  structured  programming 


(MIL71 ,RAK72b,BAK73]  use  of  the  term,  where  it  is  rigidly  urged  to 


keep  "modules"  or  sub-programs  less  than  a specified  length  (usually 
about  one  page).  Thus  a module  corresponding  to  a logical  function  or 
component  of  the  system  nay  have  sub-modules. 

Since  the  immediate  goal  of  this  research  is  the  automation  of 
stages  4 and  5 above,  the  program  design  and  coding  phases,  the  MODEL 
language  enables  a business  system  analyst  to  describe  each  desired 
progran  nodule  formally,  after  he  completes  the  stages  above  it.  In 
other  words,  MODEL  would  be  used  to  formalize  a design  after  the 
statement  and  analysis  of  requirements  is  complete,  after  the 
information  system  is  designed  and  decomposed  into  modules,  and  after 
the  files  in  and  out  of  each  nodule  are  defined.  The  MODEL  user  would 
then  write  a formal  MODEL  specification  for  each  of  the  modules  in  the 


system  and  submit  these  descriptions  to  the  MODEL  Processor.  In  turn, 
the  Processor  would  automatically  complete  the  program  design  phase 
and  proceed  to  generate  the  program,  thus  replacing  the  coding, 
debugging,  and  testing  phases. 

The  analysis  and  design  phases  preceding  the  use  of  MODEL  will  be 
done  by  the  conventional  manual  method,  at  least  for  the  near  future. 
It  is  envisioned,  however,  that  these  phases,  too,  will  some  day  be  at 
least  partially  automated  and  that  specifications  in  a language  such 
as  MODEL  could  be  produced  automatically,  from  a formal  functional 
specification  language.  Several  such  so-called  "Problem  Statement 
Languages"  exist  in  the  research  community  [HF.R73,TEI72) , and  it  would 
be  possible,  for  example,  to  take  PSL  of  the  ISDOS  Project 
[HER 73,TEI 71 ] and  transform  it  into  MODEL-like  statements  by  designing 
the  files,  decomposing  the  system  into  modules,  etc.  Research  on 
automatic  evaluation  and  selection  of  file  organizations  has  been 
reported  [CAR73]  as  well  as  work  on  automatic  system  design 
[NUN71 , PAR74] . Other  research  that  would  enable  such  a totally 
automated  system  is  actually  in  progress  [NUN71 ,CIB 75, TEI 71 ] . 

Note  that  in  Figure  3. 1 the  MODEL  Processor  automates  the  phase 
of  software  development  that  is  labelled  "design,  code,  debug,  and 
document  program  modules",  which  corresponds  to  phases  4 and  5 above. 
All  the  boxes  above  it  would  have  to  precede  the  use  of  MODEL. 
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3.1.2  MODEL  Language  Components  and  Novel  Features 

A specification  of  a module  In  the  MODEL  language  consists  of  a 
set  of  descriptive  statements  about  the  desired  module.  It  describes: 

(1)  which  files  go  in  and  out  of  the  module;  i.e.  which  files 
are  source  and  target  of  the  module); 

(2)  a description  of  each  file,  its  structure,  components, 
layout,  and  inter-relationships  (to  be  described  further); 

(3)  selection  rules  defining  subsets  of  data  to  be 
considered;  and 

(A)  assertions  on  data  relationships  (to  be  described 
further) . 

Section  3.2  will  give  a detailed  description  of  the  MODEL 
statements  including  formal  definitions  and  examples.  Some  of  the 
novel  features  that  were  incorporated  into  the  language  design  are 
summarized  here  as  follows: 

(1 ) Non-proceduralness 

Much  attention  has  been  given  in  recent  literature  [PF07A]  to 
non-proceduralness  in  languages.  Leavenworth  and  Samrv  t [LEA7A]  stated 
that  non-proceduralness  is  a relative  term  and  that  some  languages  are 
less  procedural  than  others.  Although  they  give  no  metric  for 
measuring  the  degree  of  non-proceduralness  in  a language,  they  do  give 
a list  of  characteristics  that  a language  needs  if  it  is  to  be 
considered  non-procedural  or  purports  to  lower  the  level  of 


„ 


34 


proceduralness.  Their  list  of  characteristics  includes  minimization  of 
the  amount  of  sequencing  of  statements  required  by  the  user;  a 
capability  to  state  a problem  in  terms  of  structures  relevant  to  the 
problem  rather  than  in  those  operations  convenient  for  some  machine 
organization;  aggregate  operators  (e.  g.  the  FOREACH  feature  in 
MODEL);  associative  referencing  (whereby  the  user  does  not  have  to 
specify  explicit  access  paths  or  write  an  algorithm  to  search  a data 
structure).  By  their  criteria,  MODEL  would  certainly  possess  a high 
degree  of  non-proceduralness.  Specific  aspects  of  non-proceduralness 
incorporated  into  MODEL  are  the  following: 

(a)  declarative  or  descriptive  statements  as  opposed  to 
imperative  (command)  statements:  each  statement  describes 
data  or  data  relationships  to  other  data  not  commands. 

(b)  statement  order  independence:  each  statement  consists  of 
an  independent  description,  and  the  statements  can  be 
submitted  in  any  order. 

(c)  specif icatlon  modularity  and  statement  independence:  the 
statements  can  also  be  added  in  independent  stages;  this 
corresponds  to  the  notion  of  increnentality  found  in  another 
non-procedural  language  dealing  with  automatic  test  equipment 
[PRY75] . 

(c)  absence  of  control  structures : since  the  statements  are 
indpendent  descriptions  and  can  go  in  any  order,  there  are  no 
control  structures  connecting  them.  The  sequencing  and 
control  logic  code  will  be  produced  automatically  by  the 


Processor; 


35 


(d)  absence  of  computer  programming  terminology  and  concepts: 
namely,  no  reference  to  sequences  of  operations,  control 
code.  Input  and  output  commands,  counting,  memory,  computer 
implementation,  or  generally  any  processes. 


(2 ) Machine  Independence 

The  MODEL  language  describes  an  application  module  without 
reference  to  a particular  operating  environment  or  computer  system, 
and  like  high-level  languages,  it  is  intended  to  be  usable  on  a 
variety  of  machines.  Automatic  generation  of  the  application  programs 
by  the  Processor  in  a high-level  compiler  language,  namely  PL/1,  also 
promotes  machine  independence  and  transferability. 

(3 ) Domain /Application  Independence 

The  MODEL  language  is  concerned  with  describing  information  and 
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(4)  Capability  to  Store.  Control,  and  Share  Data  Descriptions 


The  MODEL  language  was  designed  with  features  in  mind  that  in  the 
future  would  enable  sharing  common  data  descriptions  in  different 
modules  and  allow  a data  description  library  to  be  maintained 
centrally.  This  would  facilitate  the  use  of  MODEL  in  a shared  data 
base  environment  and  promote  data  and  program  independence  as  shown 
below. 


(5)  Data  and  Program  Independence 


The  capability  to  store  and  share  data  descriptions  promotes  a 
capability  to  monitor  changes  made  to  the  data  description  files. 
Thus,  whenever  changes  are  made  to  the  data  description  files,  they 
could  be  accessed  by  all  MODEL  specifications  using  them.  It  would 
then  be  possible  to  invoke  the  MODEL  Processor  in  order  to  have  it 
automatically  regenerate  affected  modules.  Therefore,  the  efficient 
method  of  compile-time  binding  of  the  data  description  to  the  program 
still  can  be  maintained,  while  having  program  and  data  independence, 
by  automatic  regeneration  of  affected  modules. 


This  last  concept  is  depicted  in  Figure  3.2.  It  is  proposed  here 
that  the  MODEL  Processor  be  augmented  with  an  automatic  monitor  to 
record  changes  to  the  data  base  description  made  via  an  editor  and 
with  an  index  correlating  every  data  description  set  with  the  modules 
that  utilize  it.  In  this  way,  the  MODEL  Processor  could  be  invoked 
automatically  by  the  monitor  to  regenerate  the  affected  modules  when 
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necessary.  Furthermore,  such  a scheme  must  be  coupled  with  an 

automatic  data  base  re-organizer  which  would  adjust  the  data  base 
accordingly  whenever  changes  are  made  to  the  data  description.  In 

short,  the  MODEL  Processor,  paired  with  library-stored  data 
descriptions  that  could  be  monitored  automatically  for  changes, 
promises  to  automate  not  only  part  of  programming,  but  partially 
automates  some  of  the  tasks  of  the  present-day  data  administrator. 

3.1.3  Language  Sections 

This  section  gives  an  overview  of  the  statement  types  in  a MODEL 
specification.  A specification  of  a module  in  MODEL  consists  of  the 

following  sections,  with  each  section  containing  certain  types  of 

descriptive  or  declarative  statements  (described  in  greater  detail  in 
subsequent  sections). 

(1)  the  header,  which  includes 

(a)  the  name  of  the  module; 

(b)  a list  of  files  which  are  source  or  input  to  the 
module ; 

(c)  a list  of  files  which  are  target  or  output  of  the 
module; 

(2)  data  description  (or  references  where  description  is 


stored),  which  includes 
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(a)  statements  describing  each  file.  Its  component 
records,  groups,  and  fields,  the  medium  on  which  it  is 
stored,  and  statements  classified  as  assertions . These  define 
the  length  of  variable-length  fields  or  the  number  of 
occurrences  of  variably-existing  groups  and  fields. 
Alternatively,  the  data  can  be  described  by  referring  to  a 
stored  description  in  a library; 

(b)  inter-file  relationships; 

(3)  Module-Specific  descriptions,  which  include 

(a)  descriptive  statements  of  any  interim  variables  not 
found  in  either  source  or  target  file  descriptions; 

(b)  source-set  assertions  which  describe  the  subset  of 
source  data  to  be  considered; 

(c)  target-set  assertions  which  describe  the  subset  of 
target  data  to  be  considered; 

(d)  other  assertions  defining  information  relationships, 
data  computations,  or  decision  rules. 

Figure  3. 3 summarizes  the  components  of  a MODEL  specification.  It 
presents  an  outline  of  the  methodology  for  a MODEL  user  to  employ  in 
preparing  his  specifications;  namely  that  the  following  steps  be 
taken: 


QBS&rcnHE: 
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HEADER 
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Assertions  for  Information  Relationships, 
and  Decision  Rules 


Computations , 


Figure  3. 3 

Components  of  a MODEL  Specification 
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(1)  the  module  should  be  named; 

(2)  the  source  files  should  be  listed; 

(3)  the  target  files  should  he  listed; 

(4)  each  file  should  be  described,  including  a description  of 
the  file  structure,  the  storage  medium,  record  layout,  and 
its  suh-conponents ; namely,  a description  of  each  field  and 
its  attributes.  Furthermore,  statements  (called  LEN  and  EXIST 
assertions  yet  to  be  described)  should  be  provided  for  each 
variable-occurring  or  variable-length  field  respectively; 
such  statements  are  used  dynamically  to  evaluate  such  data- 
dependent  quantities; 

(5)  statements  providing  inter-file  relationships  should  be 
included  to  supplement  the  file  descriptions  with 
relationships  between  files; 

(6)  interim  variables  which  are  neither  in  source  files  nor 
in  target  files  should  be  described; 

(7)  source  set  assertions  providing  selection  criteria  for 
source  files  should  be  given; 

(8)  target  set  assertions  providing  criteria  for  target  files 
should  be  given;  and 

(9)  assertions  describing  information  relationships,  data 
computations,  and  decision  rules  should  he  provided. 
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Section  3.2  will  present  detailed  rules,  methodology,  and 
examples  for  writing  the  statements  of  a MODEL  specification,  but 
first  an  example  of  an  application  of  MODEL  is  given  for  the  reader  to 
become  familiar  with  the  language. 

3.1.4  An  Example  of  an  Application  of  MODEL:  The  DEPSALE  Problem 

This  section  describes  a class  of  data  processing  applications 
for  which  MODEL  is  well-suited,  and  gives  an  example  of  the  use  of 
MODEL  by  way  of  a specific  problem.  From  the  previous  sections,  it  can 
be  inferred  that  the  MODEL  language  can  be  used  to  describe  desired 
application  programs  in  many  areas  of  data  processing.  The  class  of 
programs  that  MODEL  is  capable  of  generating  has  already  been 
discussed  in  Chapter  1.  MODEL  can  be  employed  in  applications  where 
large  amounts  of  source  data  come  in  from  already  designed  and 
existing  files;  data  gets  processed,  transformed,  or  computed  upon 
according  to  certain  defined  rules;  and  target  data  is  produced.  A 
current  restriction  is  that  files  must  be  of  either  sequential  or 
indexed  sequential  organization. 

In  order  to  make  it  easier  to  discuss  the  various  aspects  of  the 
MODEL  language  and  exemplify  its  usage,  a sample  problem  called  the 
department  store  sale  problem  (DEPSALE)  is  provided  and  defined  in 
MODEL.  Its  complete  specification  in  the  MODEL  language,  and  its 
listings  and  reports  can  be  found  in  Appendix  A.  References  are  made 
to  the  DEPSALE  problem  throughout  the  remainder  of  this  chapter  to 
exemplify  various  statements  in  MODEL  . 
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The  example  deals  with  a department  store  whose  customers 
normally  purchase  items  from  stock.  As  seen  in  Figure  3.4,  the 
function  to  be  specified  maintains  customer,  inventory,  and  sale  data 
and  issues  invoices  for  the  purchasers.  A MODEL  description  of  this 
requirement  consists  of  describing  source  and  target  data  and  business 
decision  rules.  The  specifier  need  not  make  any  references  to 
processes,  computers,  or  events.  Obviously,  the  computer  process  is 
implicit  in  that  one  purpose  of  the  description  would  be  to  produce  a 
program  that  will  generate  the  target  data  automatically. 

Assume  that  the  specifier  is  a department  store  analyst  expert  in 
management  and  accounting  practices,  but  has  no  computer  oriented 
training.  He  first  describes  the  source  and  target  data  in  MODEL;  that 
is,  the  information  obtained  from  the  purchaser  (entered  into  the 
point  of  sale  terminal),  the  composition  of  a customer-master  file,  a 
stock  inventory  file,  a sales  journal,  and  a customer  invoice. 

In  addition,  the  analyst  specifies  rules  for  decision, 
accounting,  conversion,  and  other  rules  (called  assertions  in  MODEL) 
that  would  indicate  dispositions  in  certain  eventualities,  such  as 
when  a stock  item  is  not  available  from  inventory,  or  when  a purchaser 
exceeds  the  allowed  credit  limit.  The  accounting  rules  specify  the 
determination  of  charges  for  purchases  and  the  method  of  determining 


the  customer's  balance 


In  the  above  cited  example,  the  department  store  analyst  does  not 
need  computer  programninR  knowledge  since  the  references  to  a process 
or  computer  system  is  only  implicit.  Also,  although  he  uses  his 
knowledge  of  the  department  store  business  and  department  store 
vocabulary  to  provide  data  descriptions  and  assertions,  the  vocabulary 
that  is  inherent  to  MODEL  does  not  require  specific  application 
knowledge.  Therefore,  an  analyst  in  another  business  application,  such 
as  logistics  or  insurance,  could  utilize  MODEL  as  well,  and  give  the 
MODEL  specification  the  flavor  of  his  own  application.  More 
specifically,  the  vocabulary  of  words  inherent  to  MODEL  is  oriented 
towards  data  and  assertion  description.  For  his  own  convenience,  the 
user  can  name  the  data,  records,  files,  and  assertions  using  words 
meaningful  to  his  own  particular  applications. 

In  the  future,  MODEL  program  module  specifications  could  include 
descriptions  and  assertions  of  data  which  may  be  common  to  a number  of 
programs.  Thus  once  a user  has  described  data  or  assertions,  the 
descriptions  could  be  stored  in  a library  and  there  would  be  no  need 
to  re-describe  when  specifying  another  module  that  shares  the  same 


data  or  assertions. 
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3.2  User  Reference  Manual  for  MODEL 

This  section  serves  as  a reference  for  using  the  MODEL  language. 
It  describes  in  detail  the  various  statements  MODEL.  For  each 
statement,  its  purpose,  syntax,  and  semantics  are  given,  along  with  an 
example  of  its  use,  usually  from  the  DEPSALE  problem. 

3.2.1  General  Information 

A specification  of  a module  in  MODEL  consists  of  a set  of 
statements  which  describe  the  desired  module.  Although  these 
statements  can  appear  in  any  order,  the  specification  can  be  divided 
into  the  following  sections  for  purposes  of  organization. 

(1 ) a header  whose  statements  describe  the  overall  source  and 
target  files  to  the  module; 

(2)  a data  description  section,  whose  statements  describe  the 
media,  files,  records,  groups,  and  fields; 

(3)  an  assertions  section  in  which  assertions  are  stated  for 
data  relationships  and  other  purposes  to  be  described. 

The  description  of  each  of  the  statements  starts  with  sub-section 
3.2.2,  following  a few  general  notes  here. 
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3. 2.  1.  1 Syntax  Notation 

In  the  descriptions  of  the  syntax  of  MODEL  statements  below, 
upper  case  letters  refer  to  specific  MODEL  vocabulary  or  to  user 
provided  names  and  angle-bracketed  < > lower  case  letters  refer  to  a 
generic  class  for  which  a specific  item  needs  to  be  substituted.  The 
symbol  means  "is  defined  as".  Square  brackets  [ ] indicate 
optional  portions  of  the  statements.  Asterisks  following  square 
brackets  [ ]*  signify  repetition  zero  or  more  times.  The  " | " symbol 
means  "or",  and  is  used  for  alternatives. 

The  formal  syntax  of  MODEL  is  provided  in  Section  3.3  in  the 
Extended  Backus  Normal  Form  (EBNF)  specification  language  as  a 
supplement. 


3.  2.  1.2  Names 

Whenever  a <name>  is  indicated  in  the  statements  of  MODEL,  it  may 
consist  of  1 to  8 characters  defined  below  (except  file  names  which 
are  limited  to  6 characters  due  to  various  technical  restrictions). 
The  names  chosen  by  the  user,  however,  should  not  be  one  of  the  set  of 
reserved  words:  ANSI_STD,  ASSERTIONS,  BIN,  BINARY,  BLOCKSIZE,  BYPASS, 
CARD,  CHAR,  CHARACTER,  CHOICE,  CYL,  DELIM,  DENSITY,  DISK,  EVEN,  FIELD, 
FILE,  FILES,  FIXED,  FOREACH,  FUNCTION,  CROUP,  IBM_STD,  INDEXED, 
INDEXED_SEQUENTIAL,  INTERIM,  INT_NAME,  IS,  ISAM,  KEY,  MAX_BLOCKS IZE, 
MAX_R  ECORDS I Z E , MODULE,  NONE,  NO_TRACKS,  NUMERIC,  ODD,  OP.C, 

ORGANIZATION,  PARITY,  PRINTER,  PUNCH,  RECORD,  RECORD_SIZE,  REPLACE, 


? 
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REPORT,  REPORT_ENTRY,  SERIAL#  SEQUENCE,  SPACE,  SOURCE,  START_FILE, 
STORAGE,  SUM,  TAPE,  TAPE_LABEL,  TARGET,  TERMINAL,  TODAY,  TRACKS, 
UNDEFINED,  UNIT,  UNITS,  VARIABLE,  VARIABLE_S PANNED,  VOL_NAME. 

3.  2.  1.3  Character  Set 

The  characters  which  can  be  used  to  form  names  can  be  any 
combination  of  1 to  8 letters,  dipits,  or  special  characters  defined 
below,  but  the  first  character  of  a name  must  be  a letter. 

<LETTER>::-A  |B|...|X|Y|Z 
<DICIT>: :=0  | 1 | 2 | ...  | 9 
<SPECIAL-CHARACTER>: @ | _ | # 

3. 2. 1. A Integers 

Whenever  an  <integer>  is  indicated,  it  may  be  any  combination  of 
digits  with  values  from  1 to  32767,  except  where  further  limits  are 
indicated. 


* V X*, 
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3.2.2  Specification  Header 

The  header  of  a MODEL  Specification  consists  of  three  statements, 
the  nodule  name  statement,  the  source  files  statement,  and  the  target 
files  statement,  described  below.  Taken  together,  they  form  the 
equivalent  of  the  block  diagram  of  the  desired  module. 

3. 2.2.1  Module  Dame  Statement 

Purpose : to  give  a name  to  the  desired  module. 

Syntax : 

tODULE:  <name>; 

Semantics : <name>  is  given  to  the  module. 

Example : 

MODULE:  DEPSALE; 


3. 2. 2. 2 Source  Files  Statement 

Purpose : to  indicate  the  names  of  those  files  which  are  sources  or 
inputs  to  the  desired  module. 

Syn  tax : 

SOURCE  [FILES]:  <name>  [,<name>]  * ; 

Semantics:  The  list  of  named  files  are  source  files  to  the  module. 
Example : in  order  to  indicate  that  the  files  named  TRAMS,  1NVEN, 


CUSTMAST  are  source  files  to  the  DEPSALE  module: 
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SOURCE  FILES:  TRANS,  INVEN,  CUSTMAST; 


3. 2. 2. 3 Target  Files  Statement 

Purpose:  to  indicate  the  names  of  those  files  which  are  targets  or 
outputs  of  the  desired  module. 

Syntax: 

TARGET  [FILES]:  <name>  [,<name>]*; 

Semantics:  The  list  of  named  files  are  target  files  of  the  module. 
Example:  in  order  to  indicate  that  the  files  named  SALESLIP,  JOURH, 

EXCEPT,  CUSTMAST,  and  TNVEN  are  target  files  of  the  DEPSALE  module: 
TARGET  FILES:  SALESLIP,  INVEN,  JOURN,  EXCEPT,  CUSTMAST; 

Notice  that  a file  can  be  both  source  and  target  such  as  a file 
to  be  updated  (e.g.  INVEN). 

3.2.3  Data  Description 

The  data  description  statements*  describe  each  of  the  files  or 
reports  in  the  user's  desired  module  and  their  component  records. 
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groups,  fields,  and  associated  assertions.  It  is  envisioned  that  in 
the  future  these  descriptions  could  cone  from  a library  of  many  file 
descriptions.  Each  file  is  described  both  logically  (via  the  FILE, 
RECORD,  GROUP,  FIELD  statements)  and  physically  (via  the  STORAGE 
statements).  Each  component  of  the  file  is  described  in  a separate 
statement . 

The  data  description  statements  are  purely  descriptive  in  nature. 
They  enable  the  user  to  describe  source  anti  target  tiles  that  are 
sciential  or  indexed  in  organization,  that  are  ordered  or  unordered, 
and  that  can  appear  on  a variety  of  storage  media  used  in  today's  data 
processing  community. 


* The  data  description  portion  of  MODEL  is  a modification  and 
expansion  of  the  DDL  language  of  the  University  of  Pennsylvania's  DDL 
Project  on  which  the  present  author  was  an  active  participant. 
Documentation  of  that  language  can  be  found  in  [RAM73]  and  [R IN 75 ] . 
Many  modifications  were  made  to  it  by  this  author  for  MODEL  including 
the  following: 

the  DDL  within  MODEL  consists  of  only  descriptive  statements.  The 
CONVERT,  SCAN  and  other  conversion  commands  were  removed;  the  data 
mapping  commands  were  replaced  by  the  assertion  section  of  MOREL  end 
new  implicit  rules.  All  references  to  the  old  conversion  process  in 
DDL,  including  WRAPUP,  PPECRIT,  POSTCRIT,  CONV  commands,  were  replaced 
in  MODEL  by  non-procedural  statements.  The  DDL  for  MODEL  was  enhanced 
with  facilities  to  enable  descriptions  of  new  file  organizations 
(indexed);  descriptions  of  key  fields;  dynamic  non-procedural 
expressions  of  varying-lengths  and  repetitions;  other  physical  storage 
media;  inter-file  relationships;  descriptions  o^  multiple  independent 
files,  etc. 


- - 


In  descriptions  of  hierarchical  intra-record  structures,  the  data 
description  capabilities  of  MODEL  are  roughly  equivalent  to  at  least 
those  of  COBOL.  In  addition,  MODEL  provides  facilities  to  describe 
other  attributes  such  as  varying-length  fields  and  variably-repeating 
and  optionally-existing  groups  or  fields. 

The  following  sub-sections  explain  and  exemplify  the  data 
description  statements  of  MODEL,  which  the  user  would  employ  to  define 
the  structure  and  attributes  of  each  file  and  its  components  involved 
in  the  desired  module. 

3. 2.3. 1 File  Statement 

Purpose:  to  describe  a file  and  some  of  its  attributes. 

Syntax: 

<file  name>  IS  FILE  (RECORD  IS  <recname> 

[,]  [STORAGE  IS  <storage  name>) 

[,]  [{  KEY  | SEQUENCE  > IS  <key  name>]  ) 

Semantics:  <filename>  is  the  name  of  the  file  (recall  that  file  names 
are  limited  to  6 characters,  due  to  technical  restrictions  whereas  all 
other  names  can  be  up  to  8 characters);  <recname>  is  the  name  of  the 
proto-type  record  within  the  file.  The  <storage  name>  in  the  optional 
STORAGE  clause  Is  used  to  give  the  name  of  the  statement  which  will 
describe  the  physical  attributes  of  the  device  on  which  the  file  is 
stored.  The  default  device  for  input  files  would  be  a card  reader  and 
for  output  files,  a printer.  The  <key  name>  in  the  optional  SEQUENCE 


53 


IS  or  KEY  IS  clause  is  used  to  indicate  on  which  field  the  file  is 
ordered.  The  record,  storage  medium,  and  key  field  named  above  need  to 
be  described  further  in  a record  statement,  storage  statement,  and 
field  statement,  respectively. 

In  all  the  above  discussion,  the  word  'REPORT'  may  be  substituted 
for  'FILE',  and  the  word  'REPORT_ENTRY'  may  be  substituted  for 
'RECORD',  in  order  to  describe  a report  rather  than  a file.  In  the 
current  version  of  MODEL,  no  further  provisions  are  made  for  report 
description,  and  reports  shall  be  treated  as  files.  This  decision  was 
made  knowing  that  report  description  and  generating  facilities  are 
known  technology,  and  such  report  facilities  as  headings,  footings, 
tabs,  etc.  could  be  incorporated  into  MODEL. 

Example: 

INVEK  IS  FILE  (RECORD  IS  INVREC,  STORAGE  IS  INVDISK,  KEY  IS 

STOCK#) ; 

which  says  that  IMVEN  is  a file  whose  records  are  named  INVREC.  There 
will  be  another  data  description  statement  defining  the  structure  of 
INVREC  and  so  on.  Furthermore,  the  statement  says  the  file  is  stored 
on  a device  named  INVDISK  also  to  be  described  in  another  data 
description  statement,  and  that  the  file  is  ordered  or  keyed  by  a 
field  named  STOCK#  to  be  described  later. 
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3. 2.3. 2 Storage  Statement 

Purpose:  to  describe  the  medium  on  which  a file  is  stored,  and  the 

physical  attributes  and  organization  of  the  file. 


Syntax: 


| PRINTER  [ (LINE_LENGTH  -<integer>)  ] 
<name>  is  < TAPE  (<tape-description>) 

| DISK  (<disk-description>) 

I TERMINAL  (<terminal-description> ) 


<tape-description>: :» 

<record-format>  ,V0L_NAME  -<name> 
[,INT_NAME-  <name>] 

[,NO_TRKS-  <no-trks>] 

[.PARITY-  <parity>] 

[.DENSITY-  <density>] 
[,TAPE_LABEL-  <tape-lahel>] 
[,START_FILE-  <integer>] 


<no-trks>: :-7  | 9 
<parity>: :-  ODD  | EVEN 
<density>: :-200  | 556  | 800  | 1600 
<tape-label>: : - IBM_STD,INT_NAME-  <name> 
|ANSI_STD,INT_NAME-  <name> 

| NONE 
I BYPASS 


<record-format>:  :■  FIXED  , BLOCKSIZE-  <integer> 
[.RECORDSIZE-  <integer>] 

| VARIABLE  , MAX_RLOCKSIZE-  <integer> 

[,  MAX_RECORDSIZE-  <integer>] 

| VARIABLE_S PANNED  , MAX_RLOCKS IZE-  <integer> 

[ , MAX_R ECORDS IZ E-  <integer>] 

(UNDEFINED  , MAX^BLOCKSIZE-  <integer> 


<disc-description>: :- 
[ORG-  <org-type>] 

<record-format> 

[,VOL_NAME«  <name>] 

[,INT_NAME-  <name>] 

[.UNIT-  <type-disk>] 

[.SPACE-  <units>,<integer> [ ,<integer> ] 1 
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<org-type>: :•  SEQUENTIAL  | ISAM  | INDEXED  | 

INDEXED_S  EQUENTIAL 

<type-disk>: :-2314  | 2311  | 3330  | 2305 
<units>::-  TRACKS |CYL|  <integer> 

Semantics:  <name>  is  the  name  of  the  storage  medium  as  given  in  the 

STORAGE  clause  in  the  corresponding  FILE  description  statement.  The 
storage  nedium  is  any  in  the  above  list,  each  with  its  corresponding 
physical  characteristics  of  the  file.* 

The  CARD  and  PUNCH  types  need  no  further  attributes. 

The  physical  attributes  for  the  TAPE  medium  require  the 

information  indicated,  including  the  record  format  (which  can  be 
fixed,  variable,  or  undefined ) .record  size,  and  block  size.  The  tape 
label  alternatives  have  the  following  meaning:  IBM  standard  or  ANSI 
standard  which  require  the  internal  name;  BYPASS  means  that  tape  label 
processing  is  to  be  bypassed;  NONE  denotes  no  tape  label.  The 
alternatives  for  tracks,  parity,  density,  and  file  number  within  the 
tape  should  be  self  explanatory. 


* It  should  be  explained  that  the  record  length,  and  much  of  this 
physical  information,  could  be  (and  should  be)  produced  by  the 
Processor  automatically  including  automatic  generation  of  JCL.  Such 
features  were  put  into  the  language  as  a temporary  compromise  for 
expediency. 


The  physical  attributes  for  the  DISK  medium  needs  the  information 
indicated  for  the  organization  (sequential  or  ISAM,  sequential  being 
the  default),  record  format  (fixed,  variable,  variable  spanned,  or 
undefined)  record  size,  block  size,  volume  name,  internal  name,  unit 
type,  and  space.  The  units  for  the  space  information  can  be  tracks, 
cylinders,  or  an  integer  which  indicates  number  of  bytes.  The  next 
integer  in  the  space  description  indicates  the  number  of  units  of 
primary  allocation  while  the  last  integer  indicates  secondary 
allocation  amount. 

The  physical  attributes  for  the  TERMINAL  medium  have  a similar 
description. 

The  device  specification  facilities  in  MODEL  represent  an 
apparent  contradiction  to  the  non-procedural  and  non-physical  approach 
inherent  in  MODEL.  The  reason  for  their  incorporation  is  to  facilitate 
the  use  of  MODEL  in  modification  or  additions  to  existing  systems, 
where  the  hardware  environment  is  determined  by  existing  facilities. 
Cenerally,  however,  such  information  on  the  part  of  the  user 
presupposes  that  the  file  design  and  selection  have  already  been 
performed.  The  analysis  leading  to  choice  of  source  and  target  data 
media  is  to  be  performed  either  manually  by  the  conventional  manner, 
or  some  day,  automatically  from  a Problem  Statement  Language. 


Example: 

INVniSK  IS  DISK  (ORGANIZATION-ISAM,  VARIABLE, 
MAX_BLOCKSIZE-3700,  MAX_RECORDSIZE-37,  VOL_NAME-INVOL, 
UNIT«2314);  (see  footnote  on  page  55) 
which  should  be  self-explanatory. 

3. 2. 3. 3 Record  Description 

Purpose:  to  describe  the  record  and  to  name  its  first-level  components 
in  the  tree-structured  record. 

Syntax: 

<record  name>  IS  RECORD  ( <item>  [,<item>]*  ) 

<item>: : “<item  name>  [ (<minimum>  [: <maxiraun>] )] 

Semantics:  <record  name>  is  the  name  of  the  record  as  was  given  in  the 
RECORD  clause  of  the  FILE  description  statement.  Each  <item>  is  a 
group  or  field  which  is  a component  of  the  record  in  'fhe  first-level 
of  a tree-structured  record.  Each  <iten  name>  is  the  name,of  a 
component  group  or  field.  <mininum>  is  an  optional  integer  indicating 
that  the  group  or  field  repeats  that  many  times.  A <maximuro>  integer 
is  optionally  used  in  addition  if  the  field  or  group  repeats  a 
variable  number  of  times.  If  both  a minimum  and  maximum  appear,  then 
the  following  must  hold:  0 <»  <minlmum>  < <maximum>  < 32768.  The 
attributes  of  each  member  item  are  described  further  in  later  CROUP  or 


FIELD  description  statements 
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When  a field  or  group  Is  described  to  occur  a variable  number  of 
times,  the  user  Is  also  required  to  provide  an  EXIST  type  assertion 
which  computes  the  number  of  occurrences  (see  sub-section  3.2.4. 2 
dealing  with  such  assertions). 

Example: 

STUDENT  IS  RECORD  (NAME,  SS#,  DEPT  (2),  BOURSES, 
COURSES (1 : 6) ) 

where  STUDENT  is  the  name  of  the  record,  and  NAME,  SS#,  DEPT#, 
#COURSES  are  the  component  fields  or  groups  to  be  described  further  In 
later  statements.  Notice  that  DEPT  occurs  twice  while  COURSES  repeats 
a minimum  of  one  time  and  a maximum  of  6 times. 

An  example  from  the  DEPSALE  problem  Is  the  following: 

INVREC  IS  RECORD  (STOCK#,  ITEMDESC , SALPRICE,  QOH,  TAXCODE, 
SUB ST#  (0:5)); 

Since  SUBST  here  repeats  a variable  number  of  times,  an  EXIST  type 
assertion  would  also  be  needed  (see  sub-section  3.2.4. 2 dealing  with 
such  assertions). 

3. 2. 3. 4 Croup  Description 

Purpose:  to  identify  the  name  of  a group  and  its  sub-components,  each 
of  which  In  turn  can  be  a group  or  a field. 


"turn m 


— ***  — — 


f.  * 
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Syntax: 


<name>  IS  CROUP  ( <item>  [,<item>]*  ) 


Semantics:  the  group  name  itself  should  have  been  a component  member 

within  another  group  or  in  the  record  in  a RECORD  or  CROUP  description 
statement.  The  <item>s  have  the  same  meaning  as  in  the  record 
description  statement.  If  an  item  (group  or  field)  is  defined  to 
repeat  a variable  number  of  times,  an  EXIST  type  assertion  is  also 
needed  (see  sub-section  3. 2. A. 2 dealing  with  such  assertions). 

Example: 

TRITEM  IS  GROUP  (STOCK#,  QUANTITY); 

indicates  that  the  transaction  item  is  a group  (that  was  defined  to 
occur  1 to  9 times)  which  consists  of  two  fields,  a stock  number  and 
the  quantity. 

3. 2.3. 5 Field  Description 

Purpose:  to  describe  each  field  within  each  group  or  record  of  each 

file;  to  specify  such  information  as  the  name  of  the  field,  its  length 
and  its  attributes. 

Syntax : 

<name>  IS  FIELD  (<f ield-type>  (n[:m])); 


Semantics:  <name>  is  the  name  of  the  field,  as  given  in  the  list  of 
members  in  the  field's  parent  item,  which  is  either  a group  or  a 


record; 
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<field  type>  is 

(a)  character  (CHAR  or  CHARACTER), 

(b)  binary  (BIN  or  BINARY), 

(c)  numeric  character  (NUMERIC),  or 

(d)  fixed  decimal  (FIXED,  which  is  IBM  370's  packed  decimal). 

N represents  the  length  of  the  field.  If  the  field  has  a variable 
length,  n is  the  minimum  length  and  m is  the  maximum  length,  where 
0<n<m<32768. * If  the  length  of  a field,  X,  is  specified  as  varying, 
the  user  must  in  addition  provide  a "LENGTH-type  assertion"  which  when 
evaluated  at  execution  time  yields  the  actual  length  of  the  current 
field  (see  sub-section  3.2.4. 3 dealing  with  such  assertions). 

One  of  the  primary  characteristics  of  MODEL  being  a non- 
procedural language  is  that  statements  are  independent  and  can  appear 
in  any  order.  This  principle  is  consistent,  but  does  have  one 
exception  which  relates  to  the  field  statement.  Since  the  same  field 
name  may  and  often  does  appear  in  more  than  one  file,  an  assumption  is 
made  by  the  MODEL  Processor  which  presumes  that  a field  described  in  a 
FIELD  Statement  is  associated  with  the  file  most  recently  described. 
This  however,  is  but  a slight  restriction  on  the  order-independence  of 
statements  since  the  user  would  logically  want  to  describe  each  file 
and  its  component  records,  groups,  and  fields  together.  Furthermore, 
this  restriction  appears  nowhere  else.  For  example,  assertions  in  the 
assertion  section  can  appear  in  any  order,  the  files  can  be  described 


* This  is  due  to  the  fact  that  the  length  is  stored  in  an  IBM  System- 
370  binary  half-word. 
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in  any  order,  etc. 

Example: 

NAME  IS  FIELD  (CHAR (20)); 
QUANTITY  IS  FIELD  (NUMERIC (7 )) ; 
DESCRIPT  IS  FIELD  (CHAP (1 : 20) ); 


3. 2. 3. 6 Interim  Data  Description 

Purpose:  to  describe  fields  that  are  neither  in  source  nor  target 

files. 

Syntax: 

<name>  IS  INTERIM  (<f ield-type>  (n[:m))); 

Semantics : In  the  course  of  specifying  a problem  in  MODEL,  there  would 
be  a need  to  express  assertions  involving  names  or  variables  which  are 
described  neither  in  source  files  nor  in  target  files.  When  such 
interim  variables  are  used,  their  names  and  attributes  are  described 
in  an  INTERIM  statement.  <name>,  <field  type>,  n,  and  m are  identical 
to  the  same  aspects  of  the  field  description  statement. 

Example: 

SALE#  IS  INTERIM(CllAR(5  ) ) ; 
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3. 2. 4 Assertions 

Purpose:  to  define  inter-file  relationships;  to  define  data 

relationships,  computation  rules,  and  decision  rules;  to  supplement 
the  data  description  with  rules  for  computing  variable  length  and 
repetition;  to  specify  subsets  of  data. 

Syntax: 

<assertion  name>: 

SOURCE:  <name>  [,<name>]*  ; 

TARGET:  <name>  [,<name>]*  ; 

"<assertion  text>"; 


Semantics:  The  different  types  of  assertions  fall  into  one  of  several 
categories  described  in  detail  in  sub-sections  3. 2. 4. 1 to  3. 2. 4. 6 
below. 


The  <assertion  nane>  is  an  arbitrary  name  by  which  the  user 
identifies  the  assertion.  The  list  of  names  after  the  keyword  SOURCE 
are  names  which  are  sources  or  inputs  to  the  relationship;  l.e.  are 
used  by  the  assertions.  The  list  of  names  (usually  one)  after  the 
keyword  TARGET  are  targets,  outputs,  or  resultants  of  the  conputation 
in  the  assertion.  The  format  of  the  <assertion  text>  varies  for  each 
of  the  different  types  of  assertions  and  is  described  in  the  sub- 
sections below,  but  in  general,  the  assertion  text  has  the  form 
<target-name>«<expression>. 
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It  is  true  that  the  source  and  target  header  information  for 
single  unknown  equations  can  he  deduced  from  the  assertion  itself  if  a 
convention  is  maintained  to  place  target  variables  always  by 
themselves  on  the  left  of  the  equal(“)  sign.  These  headers  are 
intended  for  future  implementations  where  the  above  rule  would  not  be 
enforced,  ^or  the  first  proto-type  version,  the  source  and  target 
identification  of  variables  are  intended  to  avoid  parsing  the 
assertion.  With  single  unknown  equations,  which  are  handled  by  MOREL, 
the  target  variable  can  be  likened  to  independent  variables  while  the 
source  variables  to  the  dependent  variables. 


3. 2. 4.1  Inter-File  Relationships:  POINTER-type  Assertions 

Purpose : to  define  inter-file  relationships 

Syntax: 

<assertton  name>: 

SOURCE:  <pointing  field>; 

TARCET:  POINTER.  <record  name>; 

"POINTER.  <record  name>  =<pointing  field>;"  ; 

Semantics : a field  in  one  file  is  said  to  "point  to"  or  be  a key  to  a 
record  of  another  file  when  the  value  of  the  field  of  the  first  file 
uniquely  identifies  a corresponding  record  in  the  other  file.  For 
example,  the  stock  number  field  (STOCK#)  in  the  sale  transaction  file 
of  the  DEPSALE  problem  points  to  a corresponding  record  in  the 
inventory  file.  Thus,  the  user  can  perceive  his  data  base  as  a network 
of  Inter-related  files,  while  the  Processor  utilizes  the  operating 
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system's  access  methods  for  data  access.  <assertion  nane>  Is  an 
arbitrary  name  for  the  assertion,  <pointing  field>  is  the  name  of  the 
field  which  serves  as  the  "pointer",  and  <record  name>  is  the  name  of 
the  record  to  which  the  field  points. 

The  user  does  not  declare  or  describe  the  special  POINTER  name  as 
he  would  for  data  fields.  The  attribute  of  the  POINTER  name  is  assumed 
to  be  a string  whose  length  is  the  same  as  the  key  field  serving  as  a 
symbolic  pointer.  Also  the  POINTER  name  itself  is  not  intended  to  be 
used  as  sources  to  other  assertions. 

Example: 

TRINV: 

SOURCE:  TRANS. STOCK#; 

TARGET:  POINTER. INVREC; 

"PO INTER. INVREC -TRAMS . STOCK#; " ; 

which  corresponds  to  the  example  mentioned  above. 

3. 2.4.2  Assertions  for  Variable  Repetition:  EXIST-type  Assertions 
Purpose:  to  provide  an  expression  that  determines  the  number  of 

occurrences  of  a variably  repeating  group  or  field. 

Syntax : 

<assertion  name>: 
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SOURCE:  <name>  [,<name>  ]*  ; 

TARCET:  EXIST.  <name>; 

"EXIST.  <name>“<arithmetic  expression>; " ; 

Semantics:  a group  or  field  can  occur  just  once,  can  repeat  a fixed 
number  of  times,  or  can  repeat  a variable  number  of  times.  In  the 
latter  case,  if  an  item  X occurs  n to  m times,  we  write  X(n:m)  in  the 
data  description,  where  0<«*n<m.  If  n is  zero,  the  group  or  field  can 
exist  optionally,  for  each  group  or  field  that  nay  exist  a variable 
number  of  times,  an  EXIST  type  assertion  must  be  provided  to  indicate 
how  many  times  the  item  exists.  This  assertion  when  evaluated  at 
execution  time  yields  the  number  of  occurrences  of  the  item.  The 
Arithmetic  expression)  has  the  usual  definition  and  can  utilize  any 
of  the  built-in  functions  (see  Sections  3. 2. 4. 5 and  3. 2. 4. 7). 

Special  treatment  and  restrictions  on  EXIST  assertions  should  be 
noted  here.  The  user  does  not  declare  or  describe  the  EXIST  name 
itself  as  he  would  for  data  fields.  The  use  of  EXIST  in  an  assertion 
implicitly  gives  the  EXIST  name  a numeric  attribute  with  a permitted 
value  from  0 to  32767.  The  user  has  to  be  careful  not  to  define 
EXIST. X in  terms  of  X,  which  would  make  no  sense.  Furthermore,  if  the 
arithmetic  expression  on  the  right  uses  other  fields,  it  must  involve 
only  fields  available  in  the  same  record  and  to  the  left  of  the  field 
or  group  whose  number  of  occurrences  is  being  defined.  For  example, 
the  number  of  occurrences  can  be  determined  as  the  value  of  another 
field  to  the  left  of  the  defined  group  or  field,  or  it  can  be 
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determined  by  a delimeter  to  the  right  of  the  group  or  field  being 
defined.  Finally,  other  assertions  may  use  the  F.XIST  value  as  sources 
if  the  above  constraints  are  met. 

Example:  if  0 were  described  to  be  a group  with  1 to  20  repetitions, 
i.e.  described  as  C(l:20),  and  if  the  actual  number  of  repetitions 
were  determined  by  the  value  of  another  field  named  F,  then  the 
following  assertion  could  he  used: 

NIJMC: 

SOURCE:  F; 

TARGET:  EXIST. G; 

"EXIST.C-F;"  ; 


3. 2.4.3  Assertions  for  Variable  Length:  LEN-type  Assertions 

Purpose:  to  provide  an  expression  that  determines  the  length  of  a 

variable  length  fields. 

Syntax: 

<assertion  name>: 

SOURCE:  <name>  [,<name>  ]*  ; 

TARGET:  LEN.  <name>; 

,fLF.N.  <name>“<arithmetic  expression:*; " ; 

Semantics:  if  the  length  of  a field  is  specified  as  varying,  the 
length  type  assertion  is  necessary  to  specify  how  the  actual  length  is 
to  be  computed. 


. l*  r 


67 

The  arithmetic  expression  has  the  usual  definition  and  can 
utilize  any  of  the  built-in  functions  (see  Sections  3. 2.4.5  and 
3.2.4.  7). 

Special  treatment  and  restrictions  on  LEW  assertions  should  be 
noted  here.  The  user  does  not  declare  or  describe  the  LEN  name  itself 
as  he  would  for  data  fields.  The  use  of  LEN  in  an  assertion  implicitly 
gives  the  LEN  name  a numeric  attribute  with  a permitted  value  from  0 
to  32767.  The  user  has  to  be  careful  not  to  define  LEN.X  in  terms  of 
X,  which  would  make  no  sense.  Furthermore,  if  the  arithmetic 
expression  on  the  right  uses  other  fields,  it  must  involve  only  fields 
available  in  the  sane  record  and  to  the  left  of  the  field  whose  length 
is  being  defined.  For  example,  the  length  can  he  determined  as  the 
value  of  another  field  to  the  left  of  the  defined  field  or  can  be 
determined  by  a delimeter  to  the  right  of  the  field  being  defined. 
Finally,  other  assertions  may  use  the  LEM  value  as  sources  if  the 
above  constraints  are  met. 

Example:  if  DESCRIP  were  described  as  DESCRIP  IS  FIELD  (CHAR(1:20))  , 

and  if  the  actual  length  were  determined  by  a delimiting  symbol 
then  the  following  assertion  could  be  used: 

LEND: 

SOURCE:  REC; 

TARGET:  LEN. DESCRIP; 

"LEN.DESCRIP«DELIM(REC,'*' );"  ; 

LEND  is  the  name  of  the  assertion;  REC  is  the  name  of  the  record  in 
which  the  delimiting  symbol  is  being  scanned;  DESCRIP  is  the  variable 
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length  field  whose  length  Is  being  defined  hy  the  built-in  DELIM 
function.  The  parameters  to  the  DELIM  function  will  be  explained  in 
sub-section  3.2. 4.7  dealing  with  functions. 

3. 2.4. 4 Subset  Selection:  SUBSET-type  Assertions 

Purpose:  to  provide  a way  for  specifying  logical  expressions 

determining  which  subset  of  a file  is  to  be  considered. 

Syntax: 

The  name,  source,  and  target  headings  as  indicated  in  Section  3.2.4, 
plus  the  following  <assertion  text>: 

IF  <logical  expression>  THEN  SUBSET.  Filename  ■ SELECTED  ; 

[ ELSE  SUBSET.  Filename  “ NOT_S ELECTED  ;] 

Semantics:  If  the  file  name  is  of  a source  file,  this  statement  is 

used  to  indicate  which  subset  of  the  source  file  is  to  be  considered 
as  applicable  to  the  module  by  means  of  a logical  expression.  This  is 

important  since  different  modules  might  want  to  look  at  different 

subsets  of  a shared  file.  In  this  case,  records  of  the  source  file 
with  name  "file  name",  should  only  be  considered  if  they  satisfy  the 
"logical  expression".  If  the  file  name  is  of  a target  file,  this 
statement  is  used  to  indicate  which  subset  of  the  target  file  is 
involved  in  the  function  of  the  module  by  means  of  a logical 
expression.  The  logical  expression  can  be  any  expression  in 

disjunctive  normal  form: 
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<name>  <relation>  <value>  [<operator>  <name>  <relation> 
<value>]  * 

where  Che  <name>  are  names  of  lcems  already  described;  <value>  is  the 
name  of  another  Item  or  a constant;  <relation>  Is  any  of  ■,  >,  <,  <■, 
>■*,  ~<,  or  ~>;  and  <operator>  is  any  valid  combination  of 

'I',  or 

This  assertion  takes  the  SOURCE  and  TARGET  headings,  as  explained 
for  the  other  assertions. 

The  user  does  not  declare  or  describe  the  special  SUBSET  name  as 
he  does  for  data  fields,  but  simply  uses  them  in  the  assertions  as 
shown  in  the  example.  The  value  of  the  subset  name  will  be  "true"  or 
"false". 

Example: 

IF  AGE  > 20  & GRADE  < 2 THEN  SUBSET. STUDENT  - SELECTED; 

3. 2.4. 5 Assertions  for  Computation  Rules 

Purpose:  to  state  data  relationships  and  computations. 

Syntax: 

Name,  source,  and  target  headings  as  indicated  in  Section  3.2.4  plus 

the  following  <assertion  text>: 

<qname>*<arithmetic  expression>  I <qname>"<character 
expression 

<qname>: :«<name>  [.<name>]*  [F0REACH_<name> J 


Semantics:  In  the  case  of  the  arithmetic  assertion,  <qname>  Is  a 
possibly  qualified  name  of  a numeric  field  (BINARY,  NUMERIC,  FIXED) 
and  <arithmetlc  expresslon>  has  the  usual  definition  Including 
constants,  other  names,  numeric  functions  (see  Section  3.2. 4. 7),  and 
arithmetic  operators(+, -,*,/,**).  In  the  case  of  assertions  dealing 
with  strings,  <qname>  is  a possibly  qualified  name  of  a character 
field  and  <character  expression>  is  some  set  of  functions  or  operators 
on  other  string  data  (string  constants  or  other  names).  Examples  of 
operators  or  functions  are  concatenation  (||)  or  any  of  the  string 
manipulating  functions  such  as  SUBSTR  (see  Section  3.2. 4. 7 on 
functions) . 

A <name>  on  either  the  left  or  right  side  of  the  must  be 
qualified  by  prefixing  it  by  the  <name>  of  its  parent  file  plus  a 
tdienever  the  field  name  appears  in  more  than  one  file.  This  is  to  make 
the  reference  to  the  field  unambiguous  and  is  exemplified  below. 

In  order  to  distinguish  between  corresponding  names  in  a file 
that  is  both  source  and  target  of  the  module,  the  prefix  "OLD."  or 
"NEW."  should  be  prefixed  before  the  entire  field  name  in  order  to 


make  the  distinction 
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Whenever  a relationship  holds  for  each  element  of  a repeating 
group  or  field,  the  word  FOREACH  appears  in  parentheses  after  the 
repeating  field  or  group.  Such  uses  of  the  FOREACH  can  appear  on 
either  the  left  or  right  side  of  the  sign  and  are  exemplified  in 
some  of  the  sample  statements  below. 

Example; 

CALCCHRC: 

SOURCE:  SSLIP. SUBTOT,  SSLIP.TAX; 

TARCET:  SSLIP. TOTCHRC; 

’’SSLIP. TOTC HRC-S  SLI P . SUBTOT 45  SLI P . TAX ; ” ; 

CALCCHRC  is  the  name  of  the  assertion.  The  source  names  are 
SSLIP. SUBTOT  and  SSLIP.TAX  . The  target  name  is  SSLIP. TOTCHRC.  The 
qualifier  SSLIP  (sales  slip)  is  used  before  the  field  names  in  this 
example  to  make  the  reference  unambiguous  with  the  same  named  fields 
in  other  files. 

Another  example  is  the  following: 

UPDOUANT: 

SOURCE:  OLD. INVEN.QOH,  TRANS . QUANTITY  (FORFACH_TRITEM) ; 
TARCET:  NEW. INVEN.QOH ; 

"NEW. INVEN. QOH-OLD. INVEN.QOH  - TRANS. QUANTITY 
(FOREACH__TFITEM) ; ’’; 

where  UPDQUANT  is  the  name  of  the  assertion;  OLD. INVEN. QOH  and 
TRANS. QUANTITY  are  the  SOURCE  names;  NEW. INVEN. QOH  is  the  target  name. 
The  reserved  word  FOREACH  indicates  that  this  relation  holds  for  each 
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of  the  components  of  that  repeating  field.  In  general,  the  FOREACH 
<name>  is  placed  in  parentheses  after  a repeating  group  or  field,  and 
it  can  appear  on  either  the  source  or  target  sides  of  the  assertion  or 
on  both.  The  reserved  words  OLD  and  MEW  before  a name  are  used  to 
distinguish  between  corresponding  field  names  in  a source  and  target 
file,  whenever  a file  is  both  a source  and  a target  to  the  module. 

3. 2. A. 6 Assertions  for  Decision  Rules:  CHOICE  Assertions 
Purpose:  to  state  assertions  that  hold  only  under  certain 

eventualities;  i.e.  to  express  conditional  relationships.  In  order  to 
facilitate  this  capability,  MODEL'S  methodology  lets  the  user  express 
such  conditional  relationships  in  two  parts  shown  below. 

Syntax: 

<assertion  name>: 

SOURCE:  <source  list>; 

TARGET:  <target  list>; 

"IF  <logical  axpression>  THEN  CHOICE.  <choice  name  1>  ** 

SELECTED ; 

[ELSE  IF  <logical  expression>  THEN  CHOICE. <choice  name  2> 

■ selected; ] * 

[ELSE  CHOICE.  <choice  name  n>  - SELECTED;]* 
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<assertlon  name>: 

SOURCE:  <8ource  list>: 

TARGET:  <target  llst>; 

"IF  CHOICE. <cholce  name  1>  THEN  <assertion>; 

ELSE  IF  CHOICE.  <cholce  name  1 > THEN  <assertlon>; 
ELSE  <assertion>; 


Semantics:  in  the  first  part,  the  user  has  a way  of  assigning  names 
(CHOICE  names)  to  any  condition.  <choice  name  1>,  ...  , <choice  name 
n>  are  the  names  that  the  user  assigns  to  each  condition  or  CHOICE 
that  is  SELECTED.  The  <loglcal  expression>  is  in  disjunctive  normal 
form: 

<elementary  logical  expresslon>  [<logical  operator> 
<elementary  logical  expression?]* 

where  <Iogical  operator?  is  &,  |,  or  and  <elementary  logical 
expression?  has  the  form  Arithmetic  expression?  <logical  relation? 
Arithmetic  expression? 

where  <logical  relation?  is  m,<t>,  <**,  >■=,  ~<,  '?,  or  An  example 
of  a logical  expression  is 

SALARY  < 10000  & ACE  ? 35; 
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Secondly,  after  all  such  conditions  are  given  names  as  they  are 
selected,  other  assertions  can  reference  those  conditions  by  their 
"CHOICE"  name.  The  reason  for  splitting  up  conditional  relationships 
in  this  way  is  that  other  assertions  can  reference  conditions  in 
arbitrary  order  without  having  to  repeat  the  logical  expressions. 

The  user  does  not  declare  or  describe  the  special  CHOICE  name  as 
he  does  for  data  fields,  but  simply  uses  them  in  the  assertions  as 
shown  in  the  examples  above.  The  value  of  the  choice  name  will  be 
"true"  or  "false". 

Example:  (CHOICE  selection  in  the  DEPSALE  problem  deciding  if  the 

customer  has  exceeded  his  credit  limit) 

EXLIM: 

SOURCE:  OLD. CUST. BALANCE,  SSLIP.TOTCHRC,  OLD. CUST. CREDLIM; 

TARGET:  CHOICE. EXCRLIM ; 

"IF  OLD . CUST . BALANCE+S SLIP. TOTC HRG  > OLD. CUST. CREDLIM  THEN 

CHOICE. EXCRLIM  - SELECTED; 


A use  of  a designated  CHOICE  name  is  the  following: 

AD J_BALC : 

SOURCE:  CHOICE. SALE,  OLD. CUST. BALANCE,  SSLI P. TOTCHPC ; 
TARGET:  NEW. CUST. BALANCE; 

"IF  CHOICE. SALE -SELECTED  THEN  HEW. CUST. BALANCE 

OLD. CUST. BALANCE  + SSLIP.TOTCHRC;"; 


It  states  that  the  new  balance  is  equal  to  the  old  balance  plus  the 
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total  charge  only  if  CHOICE. SALE  has  been  selected.  Other  assertions 
in  DEPSALE  are  similar. 

3. 2.4. 7 Use  of  Functions 

Without  the  use  of  any  functions,  MODEL  would  be  limited  to  data 
processing  applications  where  data  gets  transferred  and  relatively 
simple  computations  would  be  conducted.  Although  many  data  processing 
problems  are  of  that  nature,  use  of  functions  opens  the  door  to  much 
more,  because  functions  are  the  language  of  mathematics  augmenting 
operators. 

First,  we  have  the  built-in  functions  of  the  PL/1  library  such  as 
the  available  mathematical  functions  that  operate  on  vectors 
(ABS,MIN,MAX,  etc.)  or  string  manipulation  functions  (SUBSTR, INDEX, 
etc.).  Any  of  the  functions  available  in  the  PL/1  library  can  be  used 
in  an  assertion.  Their  use  is  documented  in  the  PL/1  reference  manual 
[PL1  75]. 

Secondly,  a capability  to  use  functions  allows  a systems 
programmer  (in  this  context,  a procedural  programmer  who  would 
maintain  the  MODEL  processor)  to  add  power  to  the  System  by  adding 
functions  to  a library.  Since  MODEL  assertions  are  limited  to 
arithmetic  functions  of  the  form  Y ■ F (XI, X2, . . . , Xn) , adding  functions 
would  enhance  MODEL'S  "knowledge".  By  definition,  MODEL  in  being  a 
non-procedural  language,  will  always  be  incomplete;  i.e.  there  will 
always  be  a computation  which  cannot  be  expressed  non-procedurally. 
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This,  however,  does  not  detract  from  the  value  of  the  language  such  as 
MODEL  for  two  reasons.  First,  the  class  of  problems  which  actually  can 
be  expressed  Is  so  large  that  It  covers  most  data  processing 
applications.  Second,  by  adding  appropriate  functions  to  a library, 
the  system's  "knowledge"  can  he  increased.  It  Is  anticipated  that  with 
a supply  of  several  dozen  of  the  most  common  functions  used  in  data 
processing,  almost  any  data  processing  problem  could  be  expressed  non- 
procedurally  in  MODEL. 

Examples  of  useful  functions  in  many  data  processing  applications 
that  could  be  added  to  the  library  are  summation,  minimum,  maximum, 
average,  and  median. 

Some  functions  have  already  been  written  and  put  into  a library 
(called  FCNS ) here.  They  are  named  DELIM,  REPLACE,  SERIAL#,  SUM,  and 
TODAY,  and  are  exemplified  in  the  DEPSALF.  problem.  The  use  of  each  of 
these  functions  is  summarized  below.  Their  actual  source  code  is 
provided  in  Appendix  B along  with  the  Processor  modules.  The  Processor 
incorporates  the  text  of  those  functions  actually  used  by  a 
specification  by  including  them  in  the  generated  program.  An 
aleternative  way  of  adding  functions  would  be  to  place  them  in  object 
form,  appended  to  the  PL/1  library  by  using,  for  example,  IBM's 
catalogued  procedure  PL1CL  (PL1  75],  Those  new  functions  already 
provided  are  summarized  here. 

Functions:  DELIM 

Purpose : to  scan  for  a specified  delimiter. 


'v.  * * 


^ r- 
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Pararoeters:  (string-name,  delimiter) 

string  name:  the  name  of  the  string  being  scanned;  i.e.  the 
name  of  the  input  record) 

delimiter:  the  character(s)  that  delimit  the  variable-length 

field 


Result:  the  number  of  characters  from  the  beginning  of  the  current 
field  up  to  but  not  including  the  specified  delimiter  is  returned. 


Function:  REPLACE 

Purpose : to  stack  a vector  of  replacements  or  alternatives  for 

successive  use. 

Parameters:  (vector-name,  number) 

vector  name:  name  of  the  list  of  replacements 

number:  the  number  of  occurrences  in  the  vector  or  the  EXIST 

name  that  currently  has  the  number  of  occurrences. 


Result:  See  Section  3. 2. 4. 8 for  a detailed  discussion  of  the  REPLACE 

function. 


Function : S ER IAL ft 


Purpose:  to  produce  serial  numbers 
Parameters:  (increment,  counter#) 


78 


Increment:  the  amount  by  which  each  number  in  the  series  is 
to  be  incremented 

counter:  a number  to  distinguish  between  different  series  of 

serial  numbers 

Result : the  next  number  in  the  series  identified  by  "counter)1/"  is 
returned,  differing  from  the  previous  number  by  "increment"  amount 

Fun ction : TODAY 

Purpose:  to  provide  today's  date 
Parameters:  none 

Resul t : the  current  date  is  returned  in  the  form  "mnn  dd,  yy",  where 

mnn  is  the  three  letter  abbreviation  of  the  month,  dd  is  the  day,  and 
yy  is  the  year. 

Function:  SUM 

Purpose : to  add  numbers  of  a vector  (repeating  fields);  not  to  be 
confused  with  another  summation  function  (SUW1AT)  alluded  to  elsewhere 
with  the  purpose  of  adding  values  of  a field  across  records. 
Parameters:  (vector  name,  index,  lower  bound,  upper  bound) 

vector  name:  name  of  repeating  field  whose  sum  is  desired 
index:  the  FOR EACH  name  corresponding  to  the  repeating  field 
lower  bound:  element  of  repeating  field  with  which  total 
starts 


upper  bound:  element  of  repeating  field  with  which  total  ends 
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Result:  the  total  of  the  elements  of  the  vector  Is  returned. 

Some  functions  do  not  complete  their  computation  upon  each 
invocation,  but  only  when  an  associated  condition  is  met.  That  is, 
some  functions  can  have  conditions  associated  with  them  which 
determine  their  completion.  A summation  function,  for  example,  could 
complete  adding  up  all  the  desired  values  of  a field  in  different 
records  only  when  it  readies  the  last  item  to  be  included  in  the 
total.  The  MODEL  Processor  maintains  a table  of  such  functions  for  its 
own  use  described  in  Chapter  A. 

Since  the  Processor  does  not  scan  the  text  of  the  assertion  for 
reasons  already  explained,  and  since  it  relies  on  the  heading  of  each 
assertion  in  the  current  version,  the  user  is  required  to  add  the 
following  to  the  heading  (following  the  SOURCE  and  TARGET  heading) 
whenever  a function  is  used  in  the  assertion: 

FUNCTION:  function  name; 

This  vrould  appear  immediately  after  the  SOURCE  and  TARGET  heading  such 
as  in  the  example  below: 

TOTX: 

SOURCE:  X, Y ; 

TARGET: Z; 

FUNCTION:  SUM; 

"Z«SUM (X,Y, ...);"; 


■ 
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3.2.4.P  Allowable  Cycles:  the  REPLACE  Function 

It  Is  clear  that  the  set  of  assertions  provided  by  the  user  must 
be  complete,  consistent,  unambiguous  and  otherwise  well-defined.  This 
will  be  dealt  with  In  more  detail  in  Chapter  4.  Specifically,  the 
assertions  cannot  be  circular.  For  example,  A being  the  source  of  R,  B 
being  the  source  of  C,  and  C being  the  source  of  A would  cause  obvious 
problems.  Although  such  cycles  are  generally  Illegal  (and  are  detected 
by  the  Processor  as  will  be  explained  in  Chapter  4),  and  although  the 
philosophy  of  the  MODEL  Language  avoids  any  expression  of  control 
structures,  there  Is  one  exception.  There  Is  a type  of  circumstance 
where  one  would  want  a set  of  assertions  reasserted,  but  based  on 
different  values.  For  example,  in  the  DEPSALE  problem  we  would  want  to 
have  a rule  that  if  a desired  stock  item  is  out  of  stock,  the 
transaction  can  be  completed  by  providing  a substitute  for  the  desired 
item  and  proceeding  with  all  the  assertions  that  define  the 
transaction,  but  with  the  replaced  substitute  item.  This  was  done  in 
the  sample  problem  by  replacing  the  value  of  the  substitute  item  as  a 
pointer  to  the  inventory  file.  In  MODEL  this  assertion  is  written  as 
follows  in  the  DEPSALE  problem: 

TRYRFPL: 

SOIIRCF:  OLD.  INVEN. SUBST#,  CHOICE. SUBSTIT,  FXIST. SUBST#; 

TARGET:  POINTER. OLD.  IfJVREC  ; 

FUNCTION:  REPLACE; 

"IF  CHOICE. SUBST -SELECTED  THEN  POINTER. OLD. INVREC  - 

P.EPLACF.  (OLD.  INVEN.  SUBSTd,  EXIST.  SUB  ST#); 


where  REPLACE  is  a function  meaning  that  all  assertions  requiring 
POINTER .OLD. INVREC  and  its  consequences  should  be  re-evaluated  with 
the  substituted  number. 

The  user  would,  of  course,  have  to  ensure  that  the  replacement  or 
substitution  will  either  not  repeat  endlessly  and  that  eventually  a 
substitute  item  will  take  a choice  which  does  not  cause  another 
replacement  (in  the  example  if  a substituted  item  would  be 
sufficiently  in  stock)  or  he  would  specify  a special  condition  (called 
EMPTY)  asserting  a relationship  in  the  eventuality  that  none  of  the 
replaced  items  would  select  a different  choice  (in  the  example,  if 
none  of  the  substitute  items  were  in  stock).  An  example  of  such  an 
"empty  list"  condition  is  the  following: 

REORDER: 

SOURCE:  CHOICE. EMPTY ; 

TARGET:  SALECODE; 

"IF  CHOICE. EMPTY  THEN  SALECODE='RO' ; 

This  signifies  that  the  message  should  be  indicated  as  "reorder"  (RO) 
if  the  list  of  substitute  items  is  empty;  i.e.  they  al)  failed  to 
complete  a sale  successfully  without  selecting  a choice  other  than 
replacement.  While  such  a specification  for  replacement  is  somewhat 
contrary  to  the  non-procedural  philosophy  of  all  the  other  MODEL 
statements,  it  does  provide  a useful  tool  in  some  data  processing 


applications 
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The  actual  code  for  the  REPLACE  function  Is  provided  In  the 
appendix. 


The  next  section  presents  a formal  specification  of  the  MODEL 
language.  Chapter  4 that  follows  describes  the  design,  methodology, 
and  algorithms  that  enable  processing  of  specifications  written  in 


MODEL. 
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3. 3 The  MODEL  Language  Described  in  EBNF 

This  section  presents  a formal  conplete  description  of  the  syntax 
of  MODEL  in  an  Extended  Backus  Normal  Form  (EBNF)  specification 
language  [RAM73].  In  the  grammar  of  MODEL  that  follows,  angle- 
bracketed  names  < > represent  syntactic  names  and  non-bracketed  names 
represent  terminal  symbols,  as  in  conventional  BNF.  Units  enclosed  in 
square  brackets  [ ] indicate  that  they  are  optional,  and  an  asterisk 
following  square  brackets  ( ]*  indicates  repetition  zero  or  more 
times.  Also,  level  numbers  are  Indicated  for  readability  to  show  the 
depth  within  the  tree  structure.  Only  the  syntactic  composition  of 
each  statement  is  shown  here.  The  semantic  constraints  associated  with 
the  overall  specification  and  the  actions  performeu  by  the  Processor 
upon  recognition  of  each  syntactic  unit  are  subjects  dealt  with  in 
Chapter  4. 
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1 l <MODEL-SPECIFICATION>: : - [<MODEL-BODY-STMTS>;  ] * 

2 2 <MODEL-BODY-STMTS>: : *»<MODULE-f!AME-STMT> 

3 | <SOURCE-FILES-STMT> 

4 | <TAROET-FILES-STMT> 

5 |<DATA-nESC-STMT> 

6 | <ASSERTIOH> 

7 | END 

8 3 <?fODULE-HAME-STMT>:  MODULE:  <NAME> 

9 3 <SOURCE-FILES-STMT>: : -SOURCE  FILES : <NAMELI ST > 

10  3 <TARCET-FILES-STMT>: : -TARGET  FILES : <NAMELIST> 

11  4 <NAMELIST>:  : **<NAME>  [,<NAMF.>]  * 

12  3 <PATA-DESC-STMT>: :»<MAME>IS<DATA-nESC> 

13  4 <DATA-DESC>: : »<FILE-STMT> 

14  | <RECORD-STMT> 


I 


15  | <CROUP-STMT> 

16  | <FIELD-STMT> 

17  | <REPORT-STMT> 

18  | <RF.PORT-ENTRY-STMT> 

19  | <INTERIM-STMT> 

20  | <STORACE-STMT> 

21  5 <FILF.-STMT>:  : -FILE  (RECORD  IS  <NAME>  [,  STOP  AGE  IS  <HAME>]  [, 
<KEY>  IS  <NAME>] ) 

22  6 <KEY>: J -KEY | SEQUENCE 

23  5 <PECORn-STMT>: : -RECORD (<ITEM-L 1ST >) 

24  5 <GROUP-STMT>: : OROUP  (<ITEM-LIST>) 

25  6 <ITF.M-LIST>:  :«<ITEM>  [,<ITEM>]* 


1 

1 
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26  7 <ITEM>: : «<NAME>  [ (<INTEGER>  (: <INTEGER>] ) ] 

27  5 <FIELT)-STMT>: : “FIELD 


ti 


28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 


(<TYPE> (<INTECER>  [:  <INTEGF,R>] ) ) 

6 <TYPE>: : -CHAR (CHARACTER |NUMERIC| BIN |BINARY|  FIXED 
5 <REPORT-STMT>:  : -REPORT  (P. F.PORT_ENTRY  IS 
[,<KEY>IS<NAME>] ) 

5 REPORT -EHTRY-STMT>:  : -RF.PORT_ENTRY(<ITEM-LIST>) 

5 <INTEF.IM-Smr>:  : -INTERIM 
(<TYPF>(<INTFCFR>[: <INTECER>] )) 

5 <STORACE-STMT>:  :-CARD 
| PUNCH 

| PRINTER  [ (LINE_LENCTH-<INTECER>)] 

| TAPE  (<RECORD-FORMAT>,  VOL_NAME«<NAME> 

[ , INT_NAME«<NAME>J 
t ,NO_TRKS-<NO-TRKS>] 

[,PAPITY-<PARITY>J 
[ , DF.NS  ITY-<DENS  IT Y>  ] 

[ ,TAPE_LABEL“<TAPE-LABEL>.  ] 

[ ,START_FILE-<INTEGER>] ) 

|D IS  K ( [ORC-<ORG-T YPE  > ] 

<RECORD-FORMAT> 

[ , VO  L_NAM  F«<NAME  > ] 

[,INT_NAME«<NAME>] 

[,UNIT«<TYPE-DISK>] 

[,SPACE-<UNITS>,<INTEGF.R>t,<INTEGER>J]  ) 

| TERMINAL  (<RECOP.n-FORMAT> 


<NAME> 


1 


r . .-■rm 
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49 

,TERMNAMF.**<NAME> 

50 

[,UNIT-<NAME>] ) 

51 

6 

<NO-TRKS>:  :-7  | 9 

52 

6 

<PARITY>:  :*)DD  | EVEN 

53 

6 

<DENSITY>: :-200  | 556  | 800  | 1600 

54 

6 

<TAPE-LABF,L>:  : «IBM_STD, INT_NAME-<NAME> 

55 

|ANSI_STD,INT_NAME-<NAME> 

56 

| NONE 

57 

| BYPASS 

58 

6 

<ORC-TYPE>: : -SEQUENTIAL  | ISAM  | 

INDEXED_S  EQUENT IAL 

59 

6 

<TYPE-DISK>: :*2314  | 2311  | 3330  f 2305 

60 

6 

<UNITS>: : -TRACKS  |CYL  | <INTECF.R> 

61 

6 

<RECORD-FORMAT>:  : -FIXED  , BLOCKS  IZF=<INTF.OER  : 

62 

[ , R ECOP.DS  IZ  E«<I  NTF.GEP  > ] 

63 

| VARIABLE  , MAX_BLOCKSIZE«<I NTEGER > 

64 

[,  MAX_F ECORDS I Z E -<I NTECER > ] 

65 

| VARIABI.E_SPANMED  , MAX_BLOCKS IZE-<I NTFGER > 

66 

[, MAXJR  ECORDS IZ E -<I NTEGER > ] 

67 

IUNDEFINED  , MAX_B LOCKS IZE-<I NTEGER > 

68 

7 <1 NTEGER >: : «<DICIT> [<DIGIT>] * 

69 

7 <DIGIT>: : -0  J 1 |...|3|9 

70 

3 <ASSERTI0!!>:  :-<NAME>: 

71 

SOURCE: <ONAME> t ,<ONAME>] *; 

72 

TARGET: <ONAME> [,<QNAME>] *; 

73 

[FUNCTION: <NAME>;] 

INDEXED 
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H 


% 


74  "<TEXT>" 

75  4 «QNAME>:  : »<NAME>  f .<NAME>]  * 

76  t (FOREACH_<NAME> )] 

77  5 <NAME>: : «<LETTER> [<CHAR>] * 

78  6 <CHAR>:  :-<LETTER>|<niGIT>|  (?  | if  | 

79  <LETTER>::«A|B|...|X|Y|Z 


CHAPTER  4 


The  MODEL  Processor 

4. 1 Overview 

This  chapter  describes  the  algorithms  and  mechanisms  of  the  MODEL 
Processor,  which  is  a software  system  performing  the  program  writing 
function.  As  was  explained  in  Section  3.1.1,  the  MODEL  Processor 
(hereafter  called  the  Processor)  has  been  designed  in  order  to 
automate  the  program  module  design,  coding,  and  debugging  phases  of 
software  development  based  on  module  specifications  in  the  non- 
procedural MODEL  language.  It  presupposes  that  the  functions  of  the 
desired  application  have  been  described  to  the  extent  that  the  file, 
inter-file,  and  intra-record  structures  have  been  described  and  that 
the  system  has  been  partitioned  into  functional  modules.  As  shown  in 
Figure  4.1,  a module  is  then  formally  described  and  specified  in  the 
MODEL  language,  whose  statements  are  then  submitted  to  the  Processor. 
Each  MODEL  statement  composed  by  the  user  is  referred  to  as  a 
desc ription . while  the  set  of  MODEL  statements  describing  a functional 
module  is  referred  to  as  a specification.  The  Processor,  in  turn, 
performs  the  analysis  (including  checking  for  the  completeness  and 
consistency  of  the  descriptions  and  the  entire  specification),  module 
design  (including  generating  a flowchart-like  sequence  of  events  for 
the  module),  and  code  generation  functions,  thus  replacing  the  tasks 
of  the  application  programmer/coder . The  Processor's  capability  to 
process  a non-procedural  specification  language  is  built  on  an 
appl ication  of  graph  theory  to  the  analysis  of  such  specifications  and 
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MODEL  Statements  | MODEL  Processor 

I 

for  each > I Spec  Anal 

Functional  Module  I Program  Design 

| Coding 


— > PL/1  Program 


| — > User  Reports 
•+ 


Figure  4.  1 


Overview  of  MODEL  Processor 
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Another  important  function  of  the  Processor  is  to  Interact  with 
the  specifier  to  indicate  necessary  supplements  or  changes  to  the 
submitted  statements. 

The  Processor  produces  a complete  Pl./l  program  ready  for 
compilation  and  execution  by  the  object  operating  system  as  well  as 
various  reports  concerning  the  specification  and  the  generated 
program.  The  Processor  output  reports  include  a listing  of  the 
specification,  a cross-reference  report,  a flowchart-like  report  on 
the  generated  program,  and  a listing  and  summary  of  the  generated 
program,  all  to  be  described  fully  later.  These  are  regenerated 
whenever  a specification  is  submitted. 

Processing  of  the  module  specification  written  in  MODEL  by  the 
Processor  consists  of  five  phases  shown  in  the  system  flowchart  of 
Figure  4.2,  which  is  the  first  refinement  of  Figure  4.1.  Some  of  these 
phases  represent  adaptions  of  known  but  state-of-the-art  technology, 
while  some  of  the  latter  phases  involve  more  novel  innovations  in 
analysis  of  the  specification  and  in  the  design  and  code-generation 
for  the  application  program. 

Each  of  the  five  phases  depicted  in  Figure  4.2  is  discussed 
below. 

Phase  (1)  Syntax  Analysis  of  the  MODEL  Module  Specification 

In  this  phase,  the  provided  MODEL  Specification  is  analyzed  to 
find  syntactic  and  some  semantic  errors.  This  phase  of  the  Processor 
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is  itself  generated  automatically  by  a meta-processor  called  a Syntax 
Analysis  Program  Generator  (SAPG),  whose  input  is  syntax  rules 
provided  through  a formal  description  of  the  MODEL  language  in  the 
F.RNF  language  (yet  to  be  discussed).  In  this  manner,  changes  to  the 
syntax  of  MODEL  during  development  and  in  the  future  can  be  made  more 
easily. 

A further  task  of  this  phase  is  to  store  the  statements  in  a 
simulated  associative  memory  for  ease  in  later  search,  analysis,  and 
processing.  Some  needed  corrections  and  warnings  of  possible  errors 
are  also  produced  in  a report  for  the  user.  Also,  a cross-reference 
report  is  produced. 

A description  of  the  Syntax  and  Statement  Analysis  phase  is 
covered  in  detail  in  Section  4.2. 

Phase  (2)  Analysis  of  MODEL  Specification 

In  this  phase,  precedence  relationships  are  determined  fron 
analysis  of  the  MODEL  data  descriptions  and  assertions,  and  the 
specification  is  analyzed  to  determine  the  consistency  and 
completeness  of  the  statements.  Each  MODEL  statement  may  be  considered 
to  be  an  independent  stand-alone  statement.  The  order  of  the  user's 
statements  is  of  no  consequence.  However,  in  analysis  of  the 
statements,  precedence  relationships  are  determined  based  on 
description  components.  These  relationships  are  used  to  form  a 
precedence  graph  on  which  the  completeness,  consistency,  ambiguity, 
and  feasibility  of  the  specification  can  be  checked.  Reports  are 
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produced  for  the  user  Indicating  the  data,  assertions,  or  decisions 
that  have  been  inadequately  described,  assumptions  that  have  been  made 
by  the  Processor,  or  contradictions  that  have  been  found,  and  reports 
are  provided  to  cross-check  the  descriptions. 

Explanation  of  this  process  is  covered  in  Section  4.3. 

Phase  (3)  Automatic  Program  Design  and  Generation  of  Sequence  and 
Control  Logic. 

This  phase  of  the  Processor  determines  the  sequence  of  execution 
of  all  events  implied  by  the  specification,  using  precedence  and  graph 
theory  techniques,  and  thereby  determines  the  sequence  and  control 
logic  of  the  desired  module.  Design  of  the  object  program  proceeds 
with  scope  and  iteration  analysis  and  flow  optimization.  The  result  of 
this  phase  is  a set  of  data  structures  representing  the  desired 
sequence  of  processes  and  flow  of  events,  sequenced,  ranked,  and 
optimized  in  their  order  of  execution.  Thus,  the  output  of  this  phase 
is  a table  that  is  similar  to  a program  flowchart  of  the  desired 
module,  and  is  subsequently  used  to  produce  a flowchart-like  report. 
This  phase  is  presented  in  detail  in  Section  4.4. 
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Phase  (4)  Code  Generation 

At  this  point  in  the  process  it  is  necessary  to  generate,  tailor, 
and  insert  the  code  into  the  entries  of  the  flowchart  to  produce  the 
program.  Code  is  produced  in  two  steps  for  purposes  of  modularity  and 
independence  of  the  target  language.  The  first  step  produces  a 
language-independent  version  of  the  flowchart-entries,  as  noted  above, 
while  this  second  step  produces  code  in  the  PL/1  programming  language. 
In  particular,  read  and  write  input/output  commands  are  generated 
whenever  the  flowchart  indicates  the  need  for  records.  Calls  to 
procedures  embodying  the  assertions  are  generated  in  the  appropriate 
places  in  the  flowchart.  Wherever  program  iterations  and  other  control 
structures  are  necessary,  program  code  for  them  is  generated. 
Declarations  for  object  program  data  structures  and  variables  are 
generated.  The  product  of  this  phase  is  a complete  program  in  a high 
level  language,  PL/1,  ready  for  compilation  and  execution.  A listing 
of  the  generated  program  as  well  as  the  flowchart-like  report  is 
produced.  This  documentation  is  not  expected  to  he  of  significance  to 
the  casual  user,  but  would  be  available  for  a computer  programmer  in 
the  event  that  it  may  be  needed  for  deeper  understanding  or  debugging. 
Just  as  the  present  high  level  PL/1  programmer  does  not  refer  to  the 
assembly  language  listing  which  may  be  a by-product  of  the 
conventional  compiler,  so  the  future  analyst  using  a MODEL  type  system 
would  not  refer  to  intermediate  level  programs  that  would  be  by- 
products. A further  product  of  this  phase  is  the  JCl.  statements  for 
the  operating  system.  The  code  generation  phase  is  covered  in  Section 
4.  5. 
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Phase  (5)  Program  Compilation  and  Execution 

This  phase  starts  with  the  PL/1  program  module  that  has  been 
automatically  produced.  With  the  generated  PL/1  program  being 
submitted  to  the  PL/1  optimizing  compiler,  program  compilation  and 
optimization  of  code  on  the  machine-language  level  is  effected.  The 
automatically  generated  program  is  then  available  for  use  in 
execution.  Section  4.6  deals  with  this  phase. 


The  remainder  of  this  chapter  expands  on  the  above  processes.  The 
following  sections  give  the  theoretical  background,  algorithms,  and 
description  of  the  system  methodology  and  above  processes  for  the 
analysis,  design,  and  program  generation  tasks.  Figure  4.3  provides  a 
tree  diagram  of  the  najor  modules,  as  well  as  the  overlay  structure  of 
the  Processor.  The  names  of  the  modules  in  this  diagram  are  referenced 
throughout  the  remainder  of  this  chapter  wherever  the  corresponding 
task  is  explained.  As  seen  at  the  top  of  Figure  4.3,  a MONITOR  governs 
the  execution  of  the  different  phases  of  the  Processor,  and  does  not 
allow  succeeding  phases  to  proceed  without  the  success  of  the  previous 
phases.  At  the  second  level  of  Figure  4.3,  the  major  phases  of  the 
Processor  are  named  (l)  SAP  (Syntax  Analysis  Program),  Section  4.2; 
(2)  NETGEN  (Network  Generation)  & NETANAL  (Network  Analysis),  Section 
4.3;  (3)  CEHFLT  (Cenerate  Flowchart),  Section  4.4;  and  (4)  CODEGEN 
(Code  Generation),  Section  4.5.  Below  this  level  of  Figure  4.3,  the 
diagram  shows  the  names  of  the  modules  subordinate  to  each  of  these 
phases.  Each  of  these  subroutines  is  discussed  at  length  throughout 
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Major  Modules  Section 


ALPHDIR 

4.2 

AI1ANAL 

4.  3 

CHECKDO 

4.4 

CHFCLAB 

4.4. 

CCSUM 

4.5. 

CODECEM 

4.5 

CRADJMT 

4.3 

CRDICT 

4.  3 
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4.3 
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4.3 
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ENEXDP 

4.  3 

ENHRREL 

4.  3 

ENIMDP 

4.3 
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Figure  4. 3a 


Index  of  Major  Modules 


this  chapter.  Figure  4.3a  provides  an  alphabetic  index  of  the  names  of 
the  major  modules  and  the  sections  in  which  they  are  discussed. 

In  order  to  exemplify  the  nature  of  the  Processor  phases 
throughout  the  analysis,  design,  and  program  generation  phases,  a 
sample  case  problem  is  described  in  Section  4.3  and  specified  in 
MODEL.  The  processing  of  that  sample  problem  (a  subset  of  the 
Department  Store  Sale  problem  of  Chapter  3)  is  followed  throughout  the 
various  phases  for  tutorial  purposes. 

One  final  note  is  that  the  reader  might  wish  to  skip  some  of  the 
following  sections  of  the  Processor  description  which  can  be  done 
depending  on  the  level  of  familiarity  or  detail  of  understanding 
desired,  ^or  example,  the  reader  might  wish  to  skip  the  sections  on 
lexical  and  syntax  analysis  if  he  is  already  familiar  with  the 
techniques  used  here,  and  go  on  to  the  heart  of  the  Processor,  phases 
2 through  4. 
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4.2  Syntax  and  Statement  Analysis 

The  first  phase  of  processing  of  MODEL  statements  is  syntax  and 
other  analysis  local  to  statements,  described  in  the  following  sub- 
sections. 'Jhile  syntax  analysis  technology  is  well-known,  advanced 
state-of-the-art  techniques  not  only  have  been  used  here,  but  also 
proved  to  be  invaluable.  Specifically,  the  capability  to  generate  the 
parser  automatically  has  enabled  rapid  development  changes.  In 

addition  to  checking  the  MODEL  statements  for  syntactic  and  some 
semantic  errors,  this  phase  also  stores  the  specification  in  an 
internal  associative  form  for  further  processing. 

4. 2. 1 EBUF,  SAPG  , and  the  Syntax  Analysis  Program 

4. 2. 1.1  Specification  of  MODEL  using  EENF  and  the  SAPC. 

The  Syntax  Analysis  Program  (SAP)  for  the  MODEL  statements  is 
mostly  generated  automatically  by  a Syntax  Analysis  Program  Generator 
(SAPG).  The  SAPG  used  is  the  one  developed  by  the  University  of 
Pennsylvania  DDL  Project  (of  which  the  author  was  a member). 
Documentation  of  its  design  can  he  found  in  [RAM73J  and  of  its 
implementation  in  [FP.E72J.  As  shown  in  Figure  4.4,  the  SAPG  produces 
the  Syntax  Analysis  Program  (SAP)  for  analyzing  MODEL  statements,  by 
inputting  a spec  if ication  of  the  MODEL  language  in  the  meta-language 
"Extended  Backus  Normal  Form  with  Subroutine  Calls"  (EBNF/WSC)  . 
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The  specification  of  the  MODEL  language  uses  the  EBNF /WSC  meta- 
language which  is  submitted  to  the  SAPC.  The  EBNF/WSC  meta-language, 
which  is  used  here  to  describe  MODEL,  was  developed  with  the  SAPC  as 
described  in  [RAM73,  FRE72].  The  nature  of  the  EBNF/WSC  meta-language 
is  reviewed  here  to  make  its  use  for  MODEL  complete. 

The  EBNF/WSC  includes  the  traditional  concepts  of  BNF.  BNF  uses 
sequences  of  characters  enclosed  in  angle-brackets  < > called  non- 
terminals to  give  names  to  grammatical  units  and  for  which 
substitutions  may  be  made.  It  also  uses  sequences  of  characters  not 
enclosed  in  brackets  which  are  in  the  object  language  (in  this  case 
MODEL  ).  BNF  consists  of  a series  of  production  rules  or  substitution 
rules  of  the  form  "A::*»B".  "A"  is  a single  non-terminal  symbol  and  "B" 
is  one  or  more  alternative  sequences  of  terminal  or  non-terminal 
symbols  that  can  be  substituted  for  A.  The  alternatives  are  separated 
by  the  meta-symbol  "|".  To  facilitate  language  description,  BNF  was 
extended  to  EBNF  with  two  more  well-known  meta-symbols:  [ ] 
representing  optionality  and  [ ]*  representing  repetition  zero  or  more 
times  (the  quotation  marks  " are  used  in  this  implementation  instead 
of  square  brackets  because  of  their  greater  availability  on  standard 
keypunches ) . 

A description  of  the  MODEL  language  using  EBNF  (without 
subroutine  calls)  was  provided  in  Section  3.3  of  Chapter  3.  As  seen 
there,  EBNF  is  sufficient  to  describe  the  syntax  of  the  object 
language  MODrL. 

Actually,  the  specification  of  MODFL  that  is  input  to  the  SAPC 
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consists  not  only  of  the  syntax  specification  of  MODF.L,  but  also  of 
subroutine  names  embedded  within  the  EBNF;  therefore  the  name  "ENBF 
with  Subroutine  Calls"  (EBNF/WSC).  The  EBNF/WSC  provides  a capability 
to  branch  to  these  subroutines  upon  successful  recognition  of  a 
syntactic  unit.  Thus,  they  can  conplete  the  SAP  to  enable  it  to  check 
some  of  the  statement  semantics,  to  encode,  to  produce  error  messages, 
ann  to  store  the  MOOFL  statements  for  later  retrieval.  The  invocations 
of  these  subroutines  are  generated  automatical lv  bv  the  SAPC.  while 
the  sunoortinp  subroutines  themselves  are  written  mamiallv.  The 
specif ication  of  the  HOD EL  language  in  the  EBNF/WSC  meta-language, 
which  is  submitted  to  the  SAP 0 appears  in  Figure  4.5.  Unlike  the 
human-oriented  EBNF  of  Chapter  3,  this  one  has  two  machine-oriented 
modifications: 

(1)  the  names  of  the  invoked  subroutines  are  embedded  in  the 
EBNF  (enclosed  in  slashes); 

(2)  the  EBtiF  itself  has  been  restructured  to  conform  to 
restrictions  explained  in  the  next  section  that  are  imposed 
by  the  SAPC  Processor.* 


* The  grammar  must  be  of  type  "LR-l”,  which  means  that  the 
grammar  is  to  be  written  in  such  a way  that  backtracking  is 
limited  to  one  token  at  each  level  in  the  tree.  Writing  the 
grammar  in  "LP-1"  form  is  made  possible  for  U0PEL  by 
inserting  many  keywords. 
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Figure  4.5 

CRtJF  ERNF  ERNF/WSC  for  MODEL 

„SC  Ref. 

otillt  4.0. 


i 


2 


3 

4 

5 

6 

7 

3 


1 <;;0ii£L_St'tClMCATIO«>:  :■  "<MODFL_FODY_STMTS>  /CLRERRF/"* 
/STMT_FL / <MODEL_S PFC IF IC ATION > 

2 <MODEL_BODY_STMTS>: /U NR ECS/ 

3.  1 |MODULE  <MOD ! JL F._M A M E_S TM T > 

4.1  | SOURCE  <SOURCE_FILES_STMT> 

5. 1 ITAPCET  <TAPCFT_FILES_STMT> 

6.1  | <HDCS> 

| <t!AME>  <DDL_OR_ASSER_STMT> 

30.  1 | END  /END IN P/ 

3.2  <HODULE_NAME_STMT>:  :«*  /MODULI/:  /M0DUL2/  <NAME>  /STMOD/ 
<ENDCHAR> 

4.2  <S01TRCE_FILES_STMT>:  "<FILE_KEYUORD>"  /SRCFL1/  /INITSFL/ 

: <SOURCE_FILELIST>  /STSRC/  <ENDCHAR> 

4.  3 <FILE_KEYWOPD>: : -FILES | FILE 

4.4  <SOURCE_FILELIST>:  /SRCFL2/  <NAME>  /CVSRC/  ",  /SRCFL2/ 

<NAME>  /SVSRC/"  * 

5.2  <TAP.GET_FILES_STMT>:  "< F I LE_KF. YVJOP. D > " /TAP.FLl / /INITTFL/ 

: <TARGET_FILELIST>  /STTAR/  <FMDCMAR > 

5.3  <TARCFT_FILF.LIST>:  /TAPH.2 / <NAMF>  /SVTAR/ 

".  /TARFL2/  <NAME>  /SVTAR/  " * 


r : 


J 
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9 6.2,30.2  <I)DL_OR_ASSER_STMT>:  /SVPDNT1/  /BADDDS2/ 

<DPLJ3R_ASSER_B0DY> 

10  6.  3,  30.  3 <DDL_OR_ASSER__BODY>:  :*  <PATAJ)ESC_STMT> 

| <ASSF.RTIONJ)ESC> 

11  6.4  <D  A TAJ)  F SC_S  TM  T > : IS  /BADDDS/  <PATA_DESCRIPTIOH> 

<ENDCHAR> 

12  7 <DATA_DESCRIPTION>: 

<FILEJ)ESC_STMT> 

I <STOPACEJ)ESC_STMT> 

| <RECORDJSTMT> 

| <GP.OUP_STMT> 

I <FIEL0_STMT> 

| <R  EPO  R T_S  TMT  > 

| <REPORT_ENTRYJSTMT> 

I <1  NT  I)ESC> 


13  8.1  <FILEJ)ESCJ5TMT>:  : = FILE  /SVFILE/  /FILERR 1 / 

( <FILE_SPECIFICATIOtJ>  ) /STFILE/ 

14  8.2  <FILE_SPF.CIFICATIOH>:  /FILERR 2/  <FII,EJ)EECRIPTION>  | 

<LIB_CALL> 

15  8.3  <FILEJ)ESCRIPTIOr!>:  :«  RECORD  "IS"  /FILERR 3/  <NAME> 

/SVRCNM/  ", "<FILE_STOP > 

16  8.4  <FILE_STOR>: 

"CHARjCODE  "IS"  /FILERR4/  <CODE>  /SVCC/" 

"STORAGE  "IS"  /FILERR 5/  <NAME>  /SVSTNtl/  " 

"<KEY>  "IS"  /FILERR 6/  <NAME>  /SVKFY / " 


17  8.5  <LIB_CALL>: : -LIBRARY  /LIBERR/  ( <NAME>  /SVLBNM/  ) 

/CETLIF  / 

18  8.6  <CODF.>:  : -EBCDIC  | BCD  |ASCI  I 

19  9 <KFY>: : -KEY (SEQUENCE 

20  10  <RECORD_STUT>:  : = RECORD  /MEMINIT / /RECERR/  (<ITEM_LIRT>  ) 

/STREC/ 

21  11  <CROUP_STMT>:  :»  GROUP  /MEMINIT/  /GRPF.RR/  (<ITEM_LIST>) 

/STGRP/ 

22  12  <ITEM_LIST>: :-<ITEM>  ",  <ITEM>"  * 

23  13.1  <ITFM>:  : - /ITEM01  / <NAME>  /SVMEM/ 

"( /MINERR/  <MIMOCC>  /SVMNOC/  <OCC_ENI)>" 

24  13.2  <OCC_F.ND>:  :-)  | : /MAXERR/  <MAXOCC>  /SVMXOC/  /CKMNMX/) 

25  13.3  <MINOCC>: <INTEGER> 

26  13.4  <MAXOCC>: :-<IMTEGER> 

27  14.1  <FIELD_STMT>: S -FIELD  /SVFLD/  <FIELD_ATTR>  /STFLD/ 

28  14.2  <FIELD_ATTR>  /FLDERR 1 / ( <TYPE>  /SVFDTP/  ( 

<MIN_LENGTH> 

/SVMNFLN / / FLDERR 2/  <MAX_L ENGTH > /SVMXFLN / " ) 

"<LIME_SPEC>"  "<COL_SPEC>"  ) 


29  14.3  <LINE_SPF.C>:  : - LIME  /LCFRR/  (<INTFGER>  /SVLINE/) 

30  14.4  <COl._SPEC>:  : « COL  /1,C ERR / (<INTECER>  /SVCOL/) 

31  14.4  <niN_LF.NGTIl>:  :-  <INTEGER> 

32  14.5  <MAX_LENCTH>: :-  <INTEGER> 

33  15  <TYPE>: : = CHAR (BIN (CHARACTER |BINARY|FIXED 

(DECIMAL INUMERIC  " TABULATED  /SVTAB/  " /STCRP/ 


T V -NX  . J 


106 


16  <RF.PORT_STMT>:  :=  REPORT  /SVRPT/  /RPTERP. / (REP0RT_F.NTRY 
"IS"  <NAME>  /SVRENM/  <FILE_ST0R>  ) /STRPT / 

17  <REPORT  ENTRY  STMT>: : -REPORT  ENTRY  /MEM I NIT / /RPTNER / ( 


<ITEM_LIST>  ) /STRPTN / 

18  <INT  DESC>: : » INTERIM  /SVINMM/  <FIEL0  ATTP>  /STINT/ 


19.1  <ST0RA0E_DESC__STMT>:  <CAR0_STMT>  | <TAPE_ST*'T> 


<0ISK  STMT>  | <PR INTER  STMT> 


<PUNCH  STMT> 


<TF.PMINAL_STMT> 

19.2  <CAPD_STMT>: :-CAR0  /STCARD/ 

19.3  <PRINTER_STMT>: :=  PRINTFP  /STPRNT/ 

19.4  <PUNCH_STMT>:  :■=  PUNCH  /STPNCH/ 

19.5  <TERMINAL_STMT>: TERMINAL  /SVTERM/  /TERMEPR/  ( 
<T ERM_D F SC_B LOC K > ) /STTERM/ 

19.6  <TERM_DESC_BLOCK>:  : *»  <REC0P.0_F0RMAT>  ","  <T ERM_NA ME_S PEC > 

"UNIT  " = " /0SKER4/  <ANY>  /SVTMIJN/  " 

19.7  <TERM_NAMF._SPEC>:  /VOLERR/  TERMNAME  <ANY>  /SVTRMNM/ 

19.8  <ANY>:  : *>  <NAMF>  | <INTECER> 

19.9  <TAPE_STMT>: :=  TAPE  /SVTAPE/  /TAPEPR/  ( <REC0RD_F0RMAT> 

<V0 1,_N AME_S PEC > 

"<INT_LAP.EL_SPEC> 

"<NO_TRKS_SPEC>" 

"<PAP ITY_S PF0 > " 

"<D F.NS ITY_S PEC > "," 

"<TAPE  LABEL  SPEO" 


"<S TA P.T_FI LE_S PE C > " ) /STTAPF./ 
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46  19.  10  <V0L_RAME_SPEC>:  /VOLERP/  VOL_NAME  <NAMF>  /SVVOL/ 

47  19.11  <INT_LABEL_SPEC>:  :»  INTJ1AMF.  /PARERR/  <NAME> 

/SVINTW1/ 

48  19.12  <NO_TRKS_SPEC>:  :«  HOJTRKS  /PARERR/  <NO_TRKS>  /SVTRK/ 

49  19.13  <PAP  IT  Y_S  PEC  >::•=  PARITY  /PARF.RR/  <PARITY>  /SVPAR/ 

50  19.14  <OENSITY_SPEC>:  nCURITY  /PARERR/  <DF.NSITY>  /SVOFN/ 

51  19.15  <TAPE_LABEL_SPEC>:  :«  TAPE_LA8EL  /PARERR/ 

<TAPE_LABEL> 

52  19.16  <STAP.T_FILE_SPEC>:  START_FILE  /PAP.ERR/  <IMTECER> 

/SVSTFL/ 

53  19.17  <DISK_STMT>:  DISK  /SVOSK/  /DSKF.R  1 / (<MSK_nESC_BLOCK>) 

/STOISK/ 

54  19.18  <DISK_DESC_BLOCK>: :=  "<ORC>  /DSKER2/  <ORC_TYPE> 

/SVOPvG/" 

<R  EC  OP.  D_F  ORM  AT  > VOL_NAME  /VOLERR  / <NAME>  /SVVOL/ 

II  It 
» 

"INT_NAME  /OSKEP3/  <NAME>  /SVINTNM/" 

"llll IT  /OSKER4 / <NAME>  /SVUNIT/" 

"SPACE  /DSKER5/  ( <SPACE_PARS>  ) ” 

55  19.19  <SPACF._PARS>:  :=  /DSKER6/  <HNITS>  , <QUANTITY>  /SVOTY/ 

M II 
9 

"<IMCREMF,NT>  /SV1NCR/"  "RI.SE  /SVRLSE/" 


56 

19.  20 

<Ol/ANTITY>:  :»  <INTFCER> 

57 

19.  21 

<ORC>:  : “ORC,  |ORGANIZATION 

58 

19.  22 

<INCREMENT>:  <INTF.GER> 

59 

20 

<N0  TRKS >: : -7 1 9 

i 


J 
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60 

21 

<PARITY>:  ODD  | EVEN 

61 

22 

<DENS ITY>: : m 200  | 556 

| 300  | 1600 

62 

23 

<TAPF,_LABEL>:  :«IBU_STD 

/SVLAB/  /TLARERR  / 

INT_NAME  <MAMF>  /SVINTN/ 

| ANSI_STD  /SVLAB / /TLABERR/  I NT_NA?'F  <NAMF> 

/SVINTN/ 

INONE  /SVLAB/ 

| BYPASS  /SVLAB/ 


63 

24 

<ORC_TYPE>: : “ISAM  | 

SEQUENTIAL  | SAM  | 

IMDF.XF,D_S  EQUENTI AI 

64 

25 

<TYPEDSK>:  : *»  2 314  | 

2311 

| 3330  | 2305 

65 

26 

<UNITS>: :=  TRACKS  | 

CYL 

/SVUNITS/  | <IN 

TECER>  /SVUNITS/ 

66 

27.  1 

<R  ECOR  D_FORM AT  > 

: : *= 

/RCFER 1 / 

<FIXED_SPEC>  | 

<VARIABLF,_SPEC>  | <VAR_SPANNED_SPFC>  | <UNDEFINED_SPEC> 
67  27.  2 <FIXED_SPEC>:  :=  FIXFO  /SVRFCF/  /RCTER  2/  BLOCKSIZE 


<BLOCKSIZE>  /SVBLK/  RECORDSIZF.  /RCFER  3/ 

<RF.COP.n_SIZE>  /SVRCSZ  / 

68  27.  3 <VARIARLF._SPFC>:  : = VARIABLE  /SVRFCF/  /RCFFR2/ 

MAX_BLOC.KSIZE  <MAX_BLOCKS IZE>  /SVBLK/ 

"MAX_P ECOF.DS IZ E "="  /RCFER 3/  <MAX_RECORDSIZE>  /SVRCSZ/  " 

69  27.4  <VAR_SPANNED_SPFC>: :=  VARJ3  PANNED  /SVRFCF/  /RCFER  2/ 

MAX_B LOC  KS I Z F,  <MAX_B  LOCKS  IZ E>  /SVBLK/ 

"MAX_R ECORDS IZ E /RCFER 3/  <MAX_R  FCOROS IZE>  /SVRCSZ/  ” 

70  27.5  <UNDFFINED_SPEC>: :=  UNDEFINED  /SVRECE/  /RCFER 2/ 

NAX_BLOCKSIZF.  <MAX_BLOCKSIZE>  /SVBLK/ 
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71  27.6  <BI.OCKS  IZK>:  <INTECER> 

72  27.  7 <RECORD_SIZE>: :«<INTEGER> 

73  27.  8 <MAX_BLOCKSIZE>:  <INTECER> 

74  27.  9 <MAX_R ECORDS IZ  F >:  : “ <1  NTECF.R > 

75  28,29  <INTCCER>: :-/INTREC/ 

76  30.4  <ASSERTIOH_DESC>: :«  : /SVASNM2/  /ASSINIT/ 

<ASSFRTION_TSODY> 

77  30.5  <ASSERTION_BODY>: : - "SOURCE  /A5SFR2/  : <SQNAME>  ", 

<SQNAME>"  * /STSR / <ENDCHAR>  " 

/ASRER 3/  TARGET  : <TQNAME>  ",  <TPNAME>"  * <ENDCIIAR> 
"FUNCTION  /FCNERR/  : <NAME>  /SVECN/  <EMDCHAR>  " /STTG/  " 

" <ASSERTION_TEXT>  /SVTXSTR/  " <ENDCHAR>  " 

78  30.6  <SQNAME>::»  /EACHINT/  <QNAME>  "(  /EACJ101/  <EACH>  /SVEACH/ 

) " /SVSR / 

79  30.7  <TQNAME>: : ■ /EACHINT/  <ONAMF>  "(  /EAGH01 / <EACH>  /SVEACH/ 

) " /RVTC/ 

80  30.8  <EACH>:  : ■ /EACHREC/ 

<F.NDCHAP>: :»  /SEMI/  ; /STMTINC/ 

<STRING_COHST>: :*  /CHARSTR/ 

81  30.9  <ASSERTIO!J_TEXT>:  /TEXTSTR/ 

82  31  <QNAME>:  :-/INITONM/  /QNMERR/  <NAHE>  /MKQNW / ".  /QNMF.RR / 

<WAME>  /MKQNH/"  * 

83  32,  33,  34  <NAME>:  : -/HAMER  EC/ 

84  35.  2 <INTF,RIM_HnG>! :«  /FRINTRM/  "DESCRIPTIONS"  ":" 

85  35.  3 <INTERFILF,JinC>:  /FR INTER/  "RELATIONSHIPS" 

86  35.4  ^ASSERTIONS  H0G>: :«  /FRASS/  "SECTION" 
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In  the  specification  of  MODEL  in  EBNF/WSC  in  this  figure,  angle- 
bracketed  names  designate  syntactic  units,  square  brackets, 
represented  for  the  SAPC  by  quotation  marks  ("),  designate  optional 
syntactic  units.  An  asterisk  (*)  following  the  optional  designation 
indicates  repetition  zero  or  more  times.  The  subroutines  to  be  invoked 
are  indicated  between  slashes  (/.../).  Mote  that  subroutine  calls  are 
made  after  the  successful  recognition  of  syntactic  units  up  to  that 
point . 

The  column  marked  "EBNF  Reference  number"  indicates  the  statement 
number  of  the  corresponding  ERNF  statement  of  Chapter  3.  Where  one 
EBMF  statement  corresponds  to  more  than  one  EBNF/WSC  statement,  a 
second  level  number  is  used. 

A representative  example  from  the  EBNF  specification  of  Chapter  3 
(statement  14)  is 

<FIEI,D_STMT>:  : -FIELD  (<TYPF.> (<INTECF.R>  [:  <INTECER>] ) ) 
in  the  EBNF/WSC  specification  on  line  52,  this  becomes  the  following: 
<FIELD_STMT>:  : -FIELD  /SVFLD/  <FIF.LD_ATTR>  /STFLD/ 

This  says  that  the  syntactic  unit  <FIELD__STMT>  (which  is  referenced  in 
a higher-level  production  rule)  starts  with  the  word  FIELD.  After 
successfully  recognizing  that,  the  subroutine  SVFLD  is  to  he  invoked 
(which  turns  out  to  be  a subroutine  that  "encodes"  the  statement  type 
as  being  a FIELD  type  statement).  By  "encode"  we  mean  compact  the 
external  statement  type  to  an  Internal  code  or  representation.  This 
subroutine  is  placed  after  FIELD  because  the  statement  type  can  only 


be  encoded  after  the  FIELD  token  is  scanned.  In  general,  encoding 
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subroutines  are  inserted  after  the  corresponding  token.  Then  the 
syntactic  unit  called  <FIF,LD__ATTR>  follows,  which  is  defined  in 
another  production  rule  (it  turns  out  to  be  the  various  types  of  field 
attributes).  Finally,  if  the  foregoing  is  recognized,  the  subroutine 
named  STFLD  is  called  (which  turns  out  to  be  a subroutine  that  calls 
the  STORE  system  to  put  the  above  information  in  the  associative 
memory,  a concept  to  be  described  further).  Such  a storing  subroutine 
must  appear  at  the  end  of  every  MODEL  statement  in  order  that  it  he 
stored  in  the  associative  memory. 

Further  examples  of  inserting  subroutine  calls  into  the  ERNF/WSC 
are  given  when  each  category  of  subroutines  is  discussed  in  later 
subsections . 

The  SAP  generated  by  the  SAPC  according  to  the  ERNF/WSC  is 
supplemented  and  linked  with  the  routines.  The  SAP,  in  turn,  accepts 
statements  in  MODEL  and  checks  them  for  syntactical  correctness,  local 
semantics,  producing  a listing  of  the  statements,  syntax  diagnostics, 
an  encoded  stored  version  of  the  MODEL  statements,  and  a cross- 
reference  report. 

More  will  be  said  about  inserting  subroutines  into  the  ERNF  in 


Sections  4.2.2  and  4.2.3. 
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4. 2. 1.2  Adequacy  and  Limitations  of  SAPG 

On  the  whole,  the  SAPG  and  the  EBNF/WSC  meta-language  is  a most 
useful  tool  for  defining  MODEL,  for  it  allows  changes  to  the  language 
to  be  made  relatively  quickly  while  it  is  undergoing  development.  The 
alternative  of  writing  the  entire  syntax  and  statement  analysis 
program  manually  would  be  even  more  tedious.  Dnlike  the  better-known 
XPL  system  [McK  71],  this  parser-generator  produces  an  ad-hoc  program 
(into  the  PL/1  language)  to  parse  the  specific  language  described 
rather  than  interpret  tables.  While  the  SAPG  approach  has  been  found 
to  be  adequate  for  future  further  development,  there  are  nevertheless 
some  limitations  to  it  that  need  to  be  mentioned  here  and  which  caused 
minor  problems  in  defining  MODEL  in  this  way. 

First,  one  obvious  limitation  is  that  SAPG  only  generates  a SAP 
to  analyze  on  a statement-by-statement  basis  for  local  syntactic  and 
semantic  correctness,  the  former  directly  and  the  latter  via 
subroutine  calls.  Since  MODEL  is  non-procedural  and  each  statement  is 
independent,  statement-by-statement  analysis  is  appropriate  as  a first 
pass.  Any  global  analysis  must  be  done  by  the  Processor  implementer. 
In  fact,  global  analysis  of  the  MODEL  specification  for  implicit 
statement  inter-relationships  is  a major  task  of  the  MODEL  Processor 
in  a later  phase  (Section  4.3). 
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A restriction  of  the  SAPC,  as  already  noted  in  footnote  3,  is 
that  it  can  only  generate  a "bounded-context"  or  "LK-k"  SAP  where  k"l. 
This  means  that  whenever  there  is  an  alternative  in  the  grammar,  the 
path  to  he  taken  is  to  he  determinable  by  the  next  token,  as 
exemplified  below.  This  restriction  is  due  to  the  fact  that  the  SAPC 
does  not  generate  a run-time  stack  of  syntactic  units  and  can  only 
"backtrack"  one  token. 


To  illustrate,  consider  the  following  three  production  rules  that 
one  might  want  to  express: 


<Y>:  :«A  R. . . 

<7.>l  :«A  C ... 

In  order  to  recognize  the  string  AC...  as  an  <X>,  a parser  capable 
of  backtracking  could  first  try  the  <Y>  alternative,  where  the  A would 
natch  but  the  C would  not.  At  this  point,  the  parser  would  have  to 
backtrack  and  try  the  <Z>  alternative  where  a match  of  A C ...  would 
be  found.  The  SAPC  does  not  have  such  a backtracking  capability,  and 
the  alternative  to  be  taken  must  therefore  always  he  determinable  by 
the  next  token.  In  order  to  conform  to  the  "LR-I"  form  that  the  SAPC 
expects,  the  above  set  of  production  rules  could  be  re-written  by 
"factoring  out"  the  "a"  as  follows: 

<X>: : -A  <Y-OP-Z> 

<Y-0R-7.>: : -<Y  > I <7. > 

<Y>: : «=  R ... 

:•=  C ... 

The  "LR-l"  restriction  was  the  reason  for  restructuring  some 
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productions  In  the  FBNF/WSC  of  MODFL.  For  example.  In  statement  11, 


the  following  production  rule 

<PATA_DF.SC_STMT>:  : **IS  /RADODS/  <DATA_DESCRIPTIOH>  <E1!T1CHAR> 
starts  with  the  terminal  " IS  ..."  rather  than  "<NAME>  IS  ..."  This 
occurs  because  the  <NAME>  was  already  factored  out  to  a higher 
production  rule,  because  <NAflE>  is  the  first  token  of  other  types  of 
statements  as  well.  This  restriction,  however,  is  still  adequate  for 
languages  such  as  MODEL,  because  the  EBNF/WSC  for  MODEL  can  and  was 
written  in  "LR-l"  form  by  "factoring  out"  common  syntactic  units  to 
higher  levels  in  the  gramnar  tree  and  using  keywords  for  unique 


identif f cation  of  path.  Thus,  although  this  restriction  makes  writing 
the  grammar  somewhat  awkward,  it  is  by  no  means  a serious  impediment 
to  the  use  of  KBNF/WSC  and  SAFE  for  defining  MODEL. 

Another  Feature  that  warrants  improvement  is  the  need  to  insert 
error-stacking  routines,  which  require  a tedious  effort  on  the  part  of 
the  language-def iner . While  the  method  of  writing  error-message 
stacking  routines  is  clear  (and  described  later),  it  could  have  been 
avoided  altogether  with  a straight-forward  extension  to  the  SAPC 
system.  There  is  no  reason  in  principle  that  the  SAPC  system  could  not 
have  been  designed  and  implemented  in  such  a way  that  it  itself 
generate  error  messages  for  missing  or  incorrect  syntactic  units  based 
on  the  names  of  the  syntactic  units  in  the  EBNF/WSC. 
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Finally,  the  SAPG  never  had  a standard  facility  for  storing 
source  language  statements.  The  processor  writer  was  responsible  for 
his  own  ad-hoc  statement  storage  procedures.  This  deficiency  has  been 
relieved  during  the  course  of  this  research  by  augmenting  the  SAPG 
system  with  a general-purpose  mechanism  for  storing  and  later 
retrieving  source  language  strings  in  a simulated  associative  memory. 
Such  a facility  (described  in  Section  4.2.4)  was  implemented  as  part 
of  this  project  as  a general  tool  that  could  he  applicable  to  other 
language  processors. 

In  conclusion,  while  the  current  status  of  the  SAPG  system  has 
some  minor  drawbacks,  it  by  all  means  has  been  an  adequate  tool  for 
defining  MODEL  now  or  for  future  changes,  and  certainly  enables  faster 
development  changes  than  does  writing  a SAP  manually. 

4. 2.1.3  How  the  SAPG  Produces  the  SAP 

As  indicated,  the  SAPG  produces  the  SAP  from  the  specification  of 
the  object  language  in  the  FBNF/WSC  meta-language.  The  design  of  the 


SAPG  is 

documented 

in  [P.AM  73] 

and  its  implementation 

in  [FRF 

72]. 

For 

completeness,  the 

technique  of 

the  SAPG  is  abstracted 

here. 

but 

the 

reader 

desiring 

greater  understanding  on  the  operation  of 

the 

SAPG 

shoul d 

refer  to 

the  above 

sources  for  detailed 

flowcharts 

and 

documentation. 


v ■** 


117 


The  SAPG  is  a small  compiler  in  itself  in  that  it  processes  a 
specification  in  the  language  EBNF/WSC  and  produces  a program  (SAP). 
It  performs  this  in  three  passes  over  the  set  of  productions. 

In  pass  1,  each  production  is  scanned,  and  its  components  are 
encoded  into  a set  of  tables.  Non-terminal  symbols  appearing  on  the 
left-hand-side  of  a production  (new  production  names)  are  put  into  a 
symbol  table,  while  non-terminals  appearing  on  the  right-hand-side  of 
a production  are  put  into  a work  table.  Terminal  symbols  in  a 
production  are  put  into  a terminal  symbol  table.  Subroutine  calls  are 
put  into  yet  another  table. 

In  pass  2,  the  symbolic  references  in  the  work  table  (i.e.  non- 
terminals on  the  right-hand-side  of  the  original  production)  are 
resolved.  Pass  2 checks  that  each  right-hand-side  non-terminal  symbol 
in  the  work  table  is  defined,  and  links  it  to  the  corresponding  entry 
in  the  symbol  table.  Undefined  non-terminals  as  well  as  circularly- 
defined  non-terminals  can  he  detected  in  these  table  searches. 

Pass  3 of  the  SAPG  is  the  code-generation  phase  that  produces  the 
SAP  in  PL/1.  It  is  only  entered  if  no  errors  were  encountered  in  the 
previous  phases.  For  each  EBHF/WSC  production,  a PL/1  procedure  is 
generated.  Each  one  returns  a bit:  1 if  the  recognition  was 
successful;  0 if  it  was  unsuccessful.  The  exclusive  nature  of  ERNF 
production  rules  and  alternatives  is  effected  by  generating  nested 
PL/1  IF-THEN-ELSE  statements.  Repetition  zero  or  more  times  is 
effected  by  generating  a CO  TO  to  the  statement  testing  for 
recognition.  Subroutine  names  embedded  in  the  EBNF/WSC  get  a CALL 


*■**£»»*  - 


generated  for  them  in  place.  Calls  to  other  subroutines  not  explicit 


in  the  EBNF/WSC  are  also  generated.  These  include  "housekeeping" 
subroutines  of  the  SAPC  and  calls  to  LEX,  a subroutine  to  scan  and 
return  the  next  token  in  the  object  language. 


To  illustrate  the  code  that  the  SAPG  generates,  consider  the 
following  representative  production  rule  in  the  EBNF/WSC  and  the  PL/1 
code  that  corresponds: 


<FIELD_STMT>:  : “FIELD  /SVFLD/  <FIELD_ATTP. > /STFLD/ 

The  PL/1  code  that  is  generated  for  it  by  the  third  pass  of  the  SAPC 

would  be  the  following: 

FIELD_STMT : PROCEDURE  RETURNS (BIT ( 1 )) ; 

CALL  SHARK; 

CALL  LEX; 

IF  LEXBUFF-'FIELD'  THEN  DO; 

CALL  LEXENAB; 

CALL  SPOPF; 

CALL  SVFLD; 

IF  FIF.LD_ATTR  THEN  DO; 

IF  ERRORS!/  THEN  DO;  CALL  SSUCCES;  RETURN  (' 1 'B ) ; END;  ELSE; 

CALL  STFLD; 

CALL  SSUCCES;  RETURN  ('  1 'B  ) ;F.ND; 

ELSE  DO;  CALL  SSUCCES;  RETURN  (' 1 'B ) ; END; 

END; 

ELSE  DO;  CALL  $FAIL ; R ETURN ('O'R ) ; END; 

END  F1ELD_STHT; 

The  above  code  generated  by  the  SAPC  would  become  one  procedure  in  the 
SAP.  Note  that  the  names  that  the  language  definer  uses  in  the 
production  rule  are  preserved  in  the  generated  SAP  code.  The 

subroutines  beginning  with  dollar  signs  (S)  are  "housekeeping" 

routines  that  are  internal  to  the  mechanisms  of  SAPC-generated  code. 
Their  detailed  logic  is  documented  in  [FRE  72]  and  really  do  not 


concern  the  language  definer 
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4.2.2  Supporting  Subroutines  for  EPNF  of  MODEL 


A refined  system  flowchart  of  the  SAPG  and  SAP  showing  the  types 
of  supporting  routines  appears  in  Figure  4.6.  The  manually-written 
syntactical  supporting  routines  are  of  one  of  several  types: 

(1 ) a lexical  analyzer  which  returns  tokens  of  syntactic 
units  to  the  SAP  for  analysis, 

(2)  statement  semantics  checking  routines; 

(3)  error  message  handling  routines; 

(4)  encoding  routines  to  compact  information  for  further 
efficient  processing;  and 

(5)  statement  storage  routines. 


The  cross-reference  report  produced  during  this  phase  is 
generated  by  a manually-vri Cten  program  (XREF)  and  Is  described  In 
Section  4.2.6. 


A discussion  on  how  to  decide  where  to  insert  subroutines  as  well 
as  a tabular  summary  of  all  routines  used  will  appear  in  Section  4.2.3 
after  a breakdown  of  the  different  categories  here. 


4. 2. 2. 1 The  Lexical  Analyzer 


The  purpose  of  the  lexical  analyzer  is  to  scan  for  syntactic 
units  or  "tokens",  using  such  delimeters  as  blanks  and  certain 
punctuation  marks,  and  to  return  them  to  the  Syntax  Analysis  Program 
(SAP)  for  syntactic  checking.  The  automatically-generated  SAP  calls 
upon  the  lexical  analyzer  (LEX)  whenever  it  needs  the  next  token.  The 
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lexical  analyzer  implemented  here  is  based  on  the  finite  state  machine 
concept  [CON63].  Each  state  of  the  machine  corresponds  to  a condition 
in  the  lexical  processing  of  a character  string.  At  each  state,  a 
character  is  read,  an  action  is  taken  based  on  the  character  read 
(such  as  concatenating  the  current  character  to  previous  ones  or 
returning  the  entire  token  to  the  SAP),  and  the  machine  changes  to  a 


new  state. 

The  character  classes 

for 

the  MODEL  Language, 

for  the 

purposes  of 

lexical 

analysis,  appear 

in 

Table  4.1.  These 

classes 

divide  the 

entire 

character  set 

into 

categories  such  as 

illegal 

characters,  delimeters,  "normal"  characters,  etc.  The  state  transition 
matrix  for  the  MODEL  language  appears  in  Table  4.2.  The  rows  of  the 
matrix  represent  the  character  classes  of  the  previous  character, 
while  the  columns  represent  those  of  the  current  character.  The 
entries  in  the  matrix  indicate  the  action  to  be  taken  and  the  next 
state.  The  action  taken  in  each  state  is  summarized  in  Table  4.3.  The 
actions  involve  such  steps  as  concatenating  of  a character,  ignoring  a 
character,  detecting  an  illegal  character,  returning  a complete  token 
to  the  RAP,  etc.,  and  setting  a "next  state". 

4. 2. 2. 2 Statement  Semantic  Analysis 

Some  of  the  semantics  of  the  specification  statements  can  be 
checked  during  the  syntax  analysis  phase.  Such  routines  can  check  that 
a range  or  condition  on  a syntactic  unit  is  locally  correct.  These 
routines  do  not  and  cannot  check  the  overall  consistency, 
completeness,  or  correctness  of  the  logic  of  the  MODEL  specification, 
a task  which  is  performed  by  a later  phase  of  the  Processor.  An 
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Class  Character  Set 


Explanation 


0 A,b, . . . , Y,Z,_. #,0  Characters  In  names 


1 (space) 


Delimeter 


0, 1,2, ... ,9 


Numerals 


Delimeters  in  various  contexts 


Qualifier  symbol 
Delim  in  logical  expr. 


"OR"  symbol 

Mult.  Or  comment  if  with  "/*" 
"NOT"  symbol 
minus  symbol 


10  / 


Division  or  comment  if  with  "/*" 


Delim  in  logical  expression 
Delim  for  keywords  & lop.  Expr. 


13  all  others 


Illegal 


Table  4. 1 


Character  Classes  for  MODEL  Language 


,.w  *.  i 


-tail!',: 


Character 

Class  (next)  012 

(current) 

0 12  1 

1 13  1 

2 12  1 

3 2 2 2 

4 2 2 1 

5 2 2 2 

6 2 2 2 

7 2 2 2 

8 2 2 2 

9 2 2 2 

10  2 2 2 

11  2 2 2 

12  2 2 2 

13  7 7 7 


123 

1111 

34567890123 

22222222227 
5 1111111117 
21222222227 
22222222227 
22222222227 
22222222217 
22212222227 
22221222227 
22122222117 
22222222127 
22226222227 
22222222217 
22222222227 
7 7 7 7 7 7 7 7 7 7 7 


Table  4.2 


State  Transition  Matrix  for  MOOF.L  Lexical  Analyzer 
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Action  1: 
Action  2: 
Action  3: 
Action  4: 
Action  5: 
Action  6: 
Action  7: 


Concatenate  next  character  to  current  token 
Fn<l  word  with  next  character 
Skips  blanks  sequence 
Reserved  (never  taken) 

Scan  forward  one  character  and  save  as  token 
Comment  bracket;  scan  to  end  of  connent 
Illegal  character(s) ; print  error  message 


Table  4. 3 


Lexical  Analysis  Actions 
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example  of  a local  semantics  checking  routine  Is  one  which  checks  the 
range  of  a numeric  computation.  Tor  Instance,  If  a group  Is  said  to 
occur  n to  m tines,  a subroutine  exists  to  check  the  0 <■  n < m < 
32768.  These  manually-written  routines  are  invoked  automatically  by 
the  SAP  by  virtue  of  their  specification  in  the  EBNF/WSC  of  the  MODEL 
language  for  the  SAPC. 

4. 2.2. 3 Error  Message  Stacking  Routines 

These  are  subroutines  which  stack  error  diagnostics  for  the  SAP 
to  print  out  upon  recognition  of  a syntactically-incorrect  user 
statement.  Upon  reaching  incorrect  syntactic  units,  the  automatically 
generated  SAP  does  not  print  its  own  messages,  but  expects  the 
corresponding  diagnostics  to  be  on  an  "error  stack."  For  this  purpose, 
subroutines  have  to  be  written  to  give  a MODEL  user  effective 
information  when  his  statements  have  been  incorrectly  composed. 
Specifically,  an  error  message  has  to  be  stacked  for  each  expected 
terminal  symbol  in  the  MODEL  language  in  case  the  token  is  missing  or 
incorrect.  If  the  expected  token  is  found,  the  SAP  simply  pops  the 
corresponding  error  message  and  continues;  if  the  expected  token  is 
missing  or  incorrect,  the  SAP  pops  the  corresponding  error  message, 
prints  the  statement  number  and  message,  scans  for  the  end  of  the 
statement  delimeter  (";"),  and  continues.  The  routines  that  stack  such 
error  message  codes  are  the  ones  ending  the  letters  "ER"  or  "ERR"  as 
found  in  the  EBNF/WSC  (e.g.  RECERR).  Each  routine's  syntax  error 
message  code  pinpoints  the  token  that  is  incorrect,  missing, 


unexpected,  or  misspelled 


One  product  of  the  syntax  analysis  phase  is  the  Error  Diagnostics 
Report  containing  the  messages.  Each  message  gives  the  diagnostics 
provided  by  the  error  routine  and  provides  the  exact  location  of  the 
error  so  that  it  can  be  corrected  and  resubmitted  by  the  user  easily. 
If  no  syntax  errors  are  found  during  the  syntax  analysis  phase,  a 
message  is  sent  that  "NO  ERRORS  OR  WARNINGS  DETECTED",  and  the 
Processor  proceeds  to  the  next  phase.  But  if  error  diagnostics  were 
produced,  a flag  is  set  to  disable  continuation  of  analysis  and  design 
beyond  the  syntax  checking  phase. 

4. 2. 2. 4 Encoding  User  Statements 

These  supporting  routines  encode  some  of  the  MODEL  specification 
into  an  internal  representation.  Although  all  of  the  names  provided  by 
the  user  specification  are  kept  intact  in  internal  form  for  use  by  the 
object  program,  many  of  the  descriptions  and  attributes  are  encoded 
for  more  compact  and  efficient  processing  later.  For  example,  the 
description  in  a FIELD  statement  enters  an  internal  table  where  the 
type  of  field  is  encoded  (0  for  character,  1 for  binary,  2 for 
numeric,  etc.),  and  the  field  length  type  is  encoded  0 for  fixed 
length,  1 for  variable  length).  One  encoding  routine  is  written  for 
each  such  statement  type.  Each  routine  is  invoked  automatically  after 
recognition  of  the  syntactic  unit  by  the  SAP.  The  invocation  is 
automatically  generated  as  part  of  the  SAP  by  the  SAPC  by  virtue  of 
its  specification  in  the  EBNF/WSC.  The  internal  format  of  the  tables 
is  given  in  the  next  section  in  conjunction  with  the  discussion  of  the 
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internal  associative  storage  of  the  MODEL  statements. 

4. 2.2.5  Statement  Storage  Routines 

These  routines  collect  the  strings  of  names  and  other  vital 
information  in  the  MODEL  statements,  and  pass  them  to  the  STORE 
system,  which  is  a sub-system  in  itself  to  store  the  statements  for 
later  processing.  Such  storage-invoking  routines  are  called  at  the  end 
of  scanning  each  MODEL  statement,  and  are  the  ones  that  begin  with  the 
letters  "ST"  as  found  in  the  EBNF/WSC  back  in  Figure  4.5  (e.g.  STFLD, 
STREC,  etc.).  The  storage  subsystem  described  below  (STORE),  which  is 
called  by  these  routines,  stores  the  MODEL  statements  in  a simulated 
associative  memory  that  facilitates  later  retrieval. 

At  the  end  of  the  syntax  pass,  we  have  the  entire  set  of  MODEL 
statements  stored  in  a convenient  storage  system  for  further  analysis. 
The  storing  subroutines  which  invoke  the  use  of  the  STORE  system  act 
as  an  interface  between  the  automatically  generated  SAP  and  the 
storage  system  presented  below.  The  storage  system  is  an  extension  to 
the  capabilities  of  the  SAPC  since  it  is  general  purpose  in  nature  and 
is  independent  of  the  nature  of  the  language  specified,  and  could  be 


used  for  processing  other  languages 


A. 2. 3 Experience  with  and  Use  of  EBNF/WSC  and  SAPC 


The  use  of  EBNF/WSC  to  describe  the  MODEL  language  and  its 
processing  by  the  SAPC  has  been  successfully  implemented  during  this 
research.  Since  this  is  only  the  second  application  of  the  SAPC  to 
implement  the  statement  analysis  phase  of  a processor,  its  u-e  is 
outlined  and  exemplified  here  as  a guide  for  further  future 
development.  Examples  from  the  EBNF/WSC  of  MODEL  presented  in  Section 
4.2.1  are  explained  here  for  illustration. 

To  use  the  SAPC,  one  first  writes  the  F.BNF  without  subroutine 
calls  representing  the  grammar  of  the  language  in  "LP-1"  form  as  shown 
in  Section  4.2.1.  One  then  proceeds  to  insert  or  embed  subroutines 
within  the  EBNF.  The  sub-sections  4. 2. 2. 1 through  4. 2. 2. 5 described 
the  different  types  of  routines  that  need  to  be  written  and  included 
in  the  EBNF/WSC  when  using  the  SAPC  system.  This  section  elaborates  on 
the  methods,  reasons  for,  and  examples  of  their  inclusion.  The 
rationale  behind  their  design  stems  from  the  way  the  SAPG  was 
implemented  and  works,  as  documented  in  [RAM  73,  FP-F.  72]. 

The  need  to  include  error  message  stacking  routines  stems  from 
the  fact  that  the  automatically-generated  SAP  does  not  print  its  own 
messages,  but  expects  the  corresponding  diagnostics  to  be  placed  on  an 
error  stack  by  routines  provided  by  the  language-def iner . Therefore, 
preceding  every  mandatory  syntactic  terminal  symbol  in  the  EBNF/WSC 
grammar  of  MODEL  , a routine  must  be  included  to  stack  an  error 
message  in  case  the  token  is  missing  or  incorrect.  The  SAP  pops  these 
messages  upon  recognizing  each  corresponding  syntactic  unit  and  prints 
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the  error  message  when  the  syntactic  unit  reached  does  not  match  that 
specified  in  the  MODEL  grammar  written  in  EBNF/WSC.  For  example, 
consider  first  the  latter  part  of  FBNF  statement  14  of  Chapter  3: 

<FI ELO_STMT>: : -F IELD ( <T YPE> (<I NTEGER > [ : <1 NTEGER > ] ) ) 

Compare  now  parts  of  the  corresponding  two  production  rules  in  the 
EBNF/WSC  of  MODEL  to  illustrate  the  use  of  error-stacking  routines 
(statements  28  and  33): 

<FIELD_ATTR>: :-/FLOERRl/  (<TYPf>  /SVFDTP/  (<MIN_LENCTM>  ... 

<TYPF,>:  : -CHAR  | BIN  |... 

The  subroutine  call  to  FI, DERR  1 has  been  inserted  at  the  beginning  of 
the  first  production,  because  it  must  anticipate  each  potential 
missing  or  incorrect  terminal  symbol  to  come,  by  stacking  error 
messages.  The  subroutine  itself  stacks  one  error  message  for  each 
anticipated  non-optlonal  terminal  symbol,  including  one  for  the  "(", 
one  for  "<TYPE>",  one  for  the  second  "(",  etc.  Notice  that  for  non- 
terminals such  as  <TYPE>,  it  makes  no  difference  whether  FLDERR1 
pushes  the  error  message  for  the  eventual  anticipated  terminal,  or 
whether  the  <TYPE>  production  below  does  it,  as  long  as  one  error 
message  is  stacked  for  each  anticipated  terminal  in  the  grammar  tree. 
Thus,  if  the  MODEL  language  is  ever  extended  or  changed  with  new 
syntactic  units  in  the  grammar,  subroutines  would  have  to  be  included 
in  the  F.RNF /WSC  preceding  each  terminal  symbol  and  must  be  written. 
The  subroutines  must  stack  one  error  message  for  each  terminal  symbol 
appearing  in  the  grammar. 


no 

The  above  example  also  Illustrates  the  use  of  encoding  routines, 
which  are  inserted  into  the  EBNF/WSC  at  the  discretion  of  the  language 
definer  whenever  there  is  a desire  to  encode  and  save  a syntactic  unit 
for  more  compact  or  efficient  processing  later.  The  subroutine  named 
SVFDTP  ("Save  Field  Type"),  for  example,  takes  the  field  type  just 
recognized  and  encodes  BINARY  as  0,  CHAR  as  1,  etc.  This  information 
is  passed  to  the  STORE  system  in  a subsequent  subroutine  (storage 
subroutines  are  discussed  below).  Such  routines  in  the  EBNF/WSC  are 
placed  after  the  corresponding  syntactic  unit,  so  that  the  syntactic 
unit  will  have  already  been  recognized  by  the  SAP. 

Poutines  for  checking  local  statement  semantics  are  optional  and 
at  the  discretion  of  the  language  definer.  They  are  inserted  in  the 
EBNF/WSC  specification  whenever  the  language  definer  wishes  to  check 
that  a range  or  condition  is  locally  correct,  something  not  possible 
to  specify  through  syntax  alone.  To  illustrate,  the  following 
production  rule  of  the  EBNF/WSC  statement  24 

<0CC_EN!1>:  : **)  | : /MAXERR/  <MAX0CC>  /SVMXOC/  /CKMNMX/ 
describes  how  to  write  the  end  of  the  number  of  occurrences  of  an  item 
in  MODEL  (after  the  minimum  was  already  given).  The  second  alternative 
is  taken  whenever  there  is  a maximum  and  a minimum,  and  consists  of  a 
coton  followed  by  the  maximum  number  of  occurrences  <MAXOCC>.  The 
subroutine  CKMNMX  ("Check  Minimum  6 Maximum")  is  inserted  here  to 
check  that  0 <=minimum  <»  maximum  < 32767  (*2**15,  the  highest 

allowed).  Thus  CKMNMX  is  an  example  of  performing  local  semantic 
analysis.  Such  routines  appear  after  the  corresponding,  syntactic  units 
so  that  they  will  have  already  been  recognized  by  the  SAP.  The  other 


two  subroutines  in  the  above  example,  MAXF.RP  and  SVMXOC,  deal  with 
error-stacking  and  encoding,  respectively. 

There  is  also  a need  to  include  a routine  in  the  EBNF/WSC  at  the 
end  of  each  production  describing  a type  of  MODEL  statement.  Such 
routines  call  the  store  system  for  storing  the  collected  tokens  in  the 
associative  memory.  These  routines  act  as  an  interface  between  the 
automatically  generated  SAP  and  the  string  storage  system  by  calling 
the  store  system  with  the  necessary  parameters.  For  example,  first 
consider  the  FBNF  production  rule  of  statement  3: 

<MOD!JLE_NAME_STMT>:  : -MODULE:  <NAHF> 

Now  consider  the  corresponding  production  rule  on  statement  3 of  the 
EBNF/WSC  describing  the  remainder  of  the  module  name  statement  (the 
keyword  MODULE  itself  appeared  previous  to  this): 

<MODULE_NAME_STMT>: : -/MODULI/  : /MODUL  2 / <NAME>  /STMOD/ 
<ENDCHAP> 

The  production  rule  consists  of  a colon,  followed  by  the  name  of  the 
module,  followed  by  the  ending  character  The  subroutine  STMOD 
("Store  Module  Name")  takes  the  pertinent  collected  tokens,  in  this 
case  Just  the  name  of  the  module  and  the  statement  type,  and  passes 
them  to  the  STORE  system  which  it  calls.  The  storage  system  itself  is 
described  later  in  this  section.  Tn  any  future  modifications  to  MODEL, 
the  language  definer  would  want  to  include  a .routine  to  invoke  the 
store  system  at  the  end  of  each  statement  described  in  the  ERNF/WSO. 
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The  MODULI  and  MODDL2  subroutines  are  error  stacking  routines 
that  stack  error  messages  for  anticipated  terminal  symbols  as 
described  earlier  (here  an  error  message  is  stacked  for  the  colon  and 
the  name  in  case  they  are  illegal  or  missing). 

The  lexical  analyzer  described  in  Section  4. 2. 2.1  does  not  have 
to  be  indicated  in  the  ERNF/WSC,  but  has  to  be  written  to  scan  for 
tokens.  Its  need  stems  from  the  fact  that  the  SAPO  only  generates  a 
call  to  the  lexical  analyzer,  which  is  expected  to  find  the  next  unit. 
This  is  due  to  the  fact  that  the  rules  by  which  lexical  units  are 
found  are  based  on  combinations  of  delimeters  or  punctuation  marks, 
which  may  vary  from  language  to  language.  Although  the  lexical 
analyzer  described  here  is  specific  to  scanning  for  tokens  in  the 
MODEL  language,  it  has  general  applicability  because  it  is  table- 
driven.  If  the  MODEL  language  is  ever  extended  or  changed  with  new 
punctuation  marks  or  delimeters  being  introduced,  it  would  simply 
require  the  new  characters  to  be  placed  in  an  appropriate  class  in  the 
character  class  table  (Table  4.1)  and  to  designate  in  the  state 
transition  matrix  (Table  4.2)  the  proper  action  to  be  taken  upon 
reaching  that  character. 

Finally,  there  are  just  a few  "housekeeping"  type  subroutines 
which  need  not  be  written  by  the  language  definer  because  they  are 
provided  by  the  SAPG  , but  which  need  to  be  included  in  the  FRNF/DS 0. 
The  very  first  production  in  the  ERNF/USC  of  MODEL  illustrates  two  of 
the  subroutines.  It  differs  from  all  of  the  other  production  rules  and 
perhaps  needs  clarification: 


/CLRERPF/] * 


<!1CDEL_SPECIFICATI0N>:  : = [<MODF.L_BODY_STMT> 

/STMT_FL/  <MODEL_SPFCIFICATION> 

<MODEL_SPECIFICATIOt!>  is  the  goal  symbol  which  is  defined  as  zero  or 
more  <MODEL_RODY_STMTS  >,  each  of  which  is  further  defined  as  one  of 
the  statement  types  of  MODEL.  After  each  such  statement  is  recognized, 
this  production  causes  further  attempts  to  be  made  to  recognize  more 
statements  (via  the  asterisk  repetition  operator).  The  subroutine 
CLRERRF  ("riear  Error  Flag")  is  a SAPC  provided  housekeeping  routine 
which  resets  a flag  indicating  presence  of  an  error.  SAPG  requires 
that  it  be  called  at  the  end  of  each  statement  (see  [FRE  72]). 
Continuing  with  the  production  explanation,  if  a statement  which 
matches  none  of  the  <MODEL_BODY_S  TMT>  types  is  encountered,  the 
production  indicates  to  branch  to  the  subroutine  STMT_FI.  ("Statement 
Fail").  This  subroutine  scans  the  text  for  the  statement  delimeter 
to  begin  scanning  the  next  statement.  Finally,  the  last  nonterminal 
<MOPEL_SPECIFICATION>  causes  the  SAP  to  attempt  recognizing  another 
statement  by  calling  the  same  production  recursively. 

The  two  other  housekeeping  routines  of  SAPC  which  are  applicable 
to  languages  other  than  MODEL  appear  elsewhere.  One  is  ENDINP  ("end 
input",  on  statement  2),  which  is  called  at  the  end  of  the  input  text. 
The  other  is  STMTINC  ("Statement  Increment",  on  statement  80),  a 
subroutine  called  after  recognizing  each  statement  delimeter  in 


order  to  increment  the  statement  number 


The  subroutine  names  used  in  the  specification  of  MODEL  were 
shown  at  the  bottom  of  the  EBNF/WSC  listing.  They  can  be  classified 
into  one  of  the  following  five  types  of  subroutines:  error  message 
stacking  routines,  encoding/saving  routines,  storing  routines, 
semantics  checking  routines,  and  housekeeping  routines.  The  tables 
provide  an  alphabetical  listing  of  the  routines  within  each  category. 
In  the  case  of  error  message  routines,  the  error  codes  and  their 
meanings  are  shown.  For  the  other  types  of  routines,  their  name  and 


tasks  are  shown. 
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Storing  Routines 

(Inserted  at  the  end  of  each  type  of  statement  of  the  FRNF/WSC  in 
order  to  call  STORK  to  put  the  statement  In  the  associative  memory) 
NAMF  STMT  WHAT  IT  STORES 


STCARD 

38 

Stores 

CARP  statement 

STDISK 

53 

Stores 

DISK  statement 

STFILF 

13 

Stores 

FILE  statement 

STFLD 

27 

Stores 

FIELD  statement 

STCRP 

21 

Stores 

GROUP  statement 

STINT 

36 

Stores 

INTERIM  statement 

STMOD 

3 

Stores 

MODULE  statement 

STPNCU 

40 

Stores 

PUNCH  statement 

ST  PR  NT 

39 

Stores 

PRINTER  statement 

STREC 

20 

Stores 

RECORD  statement 

STRPT 

34 

Stores 

REPORT  statement 

STRPTM 

35 

Stores 

REPORT-ENTRY  statement 

STSH 

77 

Stores 

SOURCE  portion  of  assertion 

STSRC 

4 

Stores 

SOURCE  FILES  statement 

STTAPF 

45 

Stores 

TAPE  statement 

STTAR 

7 

Stores 

TARGET  files  statement 

STTF.RM 

41 

Stores 

TERM  statement 

STTG 

77 

Stores 

TARGET  portion  of  assertion 
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Semantics  Checking  Routine 

(Inserted  In  the  EBKF/WSC  after  the  token(s)  to  be  checked  or 
other  action) 

NAME  STMT 'WHAT  IT  DOES 


ASSINIT 

CKMNMX 

EACH I NT 

EACHREC 

FP.ASS 

FR INTER 

FRINTRM 

GETLIP. 

INITQNI1 

IMITSFL 

INITTFL 

IMTREC 

MEMIMIT 

MKONM 

NAMEREC 


77  Initializes  number  of  sources/targets  to  assertion 
24  Checks  proper  range  for  minimum  and  maximum 

78  Initializes  flag  for  FOREACH  existence 

8n  Recognizes  FOREACH  phrase 

86  Prints  frame  before  first  assertion 
85  Prints  frame  before  interfile  relationship 

84  Prints  frame  before  interims 

17  Gets  input  from  library 

82  Initializes  number  components  to  qualified  name 

4 Initializes  source  file  list 

7 Initializes  target  file  list 

75  Recognizes  integers 

20,21  Initializes  number  of  members  of  record  or  group 

82  Concatenates  qualified  name  components 

83  Name  recognizer;  checks  not  keywords 


■>  V 


for 
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"Housekeeping"  Routines 

(inserted  in  the  EBNF/WSC  in  order  to  perform  services  provided  by  the 
SAPC 

NAME  STMT  WHAT  IT  P01S 

CLRERRF  1 Clears  "error"  flag  after  every  statement  to 
indicate  no  syntax  errors  yet  in  next  statement 
STMT_FL  1 Scans  for  end  of  statement  delimeters  when 
unrecognizable  statement  encountered 
ENPINP  2 Executed  upon  end-of-file  to  print  last  line  and  wrap-up 

STMTINC  80  Increments  the  statement  number;  called  at  end  of  each 

statement 


* ! 


*ir 
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Error  Message  Stacking  Routines 

(Inserted  In  the  EBNF/USC  before  each  anticipated  terminal  symbol). 


NAME 

CODE 

ERROR  MESSAGES 

ASSER1 

ASS  ER  1 
ASSER2 

SECTION  keyword  missing  In  heading 
Colon  missing  in  assertion  heading 

ASSER2 

ASSER3 

Colon  missing  after  keyword  SOURCE 

ASSER3 

AS  SEP.  4 
AS SEP  5 

TARGET  keyword  missing  In  assertion 
Colon  missing  after  keyword  TARGET 

BADDDS 

BADDDS 

Unrecognizable  data  description 

BADDDS 2 

BADDS2 

Invalid  keyword  beginning  data  description 
or  assertion 

DSKER1 

DISK01 

Left  paren  missing  in  DISK  statement 

DISK02 

Right  paren  missing  in  DISK  statement 

DSKER2 

DISK03 

Organization  type  missing  or  illegal 
DISK  statement 

in 

DSKER3 

DISK04 

Internal  name  missing  or  illegal  in 
statement 

DISK 

DSKER4 

DISK05 

Type  disk  missing  or  illegal  in  DISK 
statement 

DSKER5 

DISK06 

Left  paren  missing  in  SPACE  spec  in 
statement 

DISK 

DISK07 

Right  paren  missing  in  SPACE  spec  in 
statement 

DISK 

DSKER6 

DISK08 

Units  missing  or  illegal  in  DISK  statement 

SPACE  spec 


■ 
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DISK09 

Comma  missing  after  units  in  DISK  statement 
SPACE  spec 

DISK 10 

Quantity  missing  or  illegal  in  DISK 
statement  SPACE  spec 

EACH01 

EACH01 

FOREACH  name  missing  or  illegal  in 
assertion 

FCNERP. 

FCNER1 

Colon  missing  after  FUNCTION  keyword 

FCKER2 

FUNCTION  name  missing 

FCNER3 

Semi-colon  missing  after  function  name 

FILERR1 

FILE01 

Left  paren  missing  in  FILE  or  REPORT 
statement 

FILE02 

Right  paren  missing  in  FILE  or  REPORT 
statement 

FILERR2 

FILE 03 

Keyword  missing  in  FILE  or  REPORT  statement 

FILERR3 

FILE 04 

Record  name  missing  or  illegal  in  FILE  or 
REPORT  statement 

FILEP.R4 

FILE05 

Character  code  missing  or  illegal  in  FILE 
or  REPORT 

FILER?.  5 

FILE06 

Medium  name  missing  or  illegal  in  FILE  or 
RFPORT  statement 

FILERR6 

FI LEO 7 

Keyname  missing  in  FILE  or  REPORT  statement 

FLDERR1 

FL001 

Left  paren  missing  in  FIELD  statement 

FL002 

Field  type  missing  or  illegal  in  FIELD 
statement 

FI,  DO  3 

Left  paren  missing  before  length  in  FIELD 

statement 
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FLD04  Length  missing  or  illegal  in  FIELD 
statement 

FLD05  Right  paren  missing  in  FIELD  statement 

FLD06  Right  paren  missing  in  FIELD  statement 

FLDERR2  FLD07  Maximum  length  missing  or  illegal  in 
variable  length  in  FTF.LD  statement 
GRPERR  GRP01  Left  paren  missing  in  GROUP  statement 
GRP02  Right  paren  missing  in  GROUP  statement 
INTER  1 INT01  Colon  missing  in  INTERIM  heading 
INTER 2 INT02  Keyword  INTERIM  missing  in  INTEPI” 

statement 

INT03  Left  paren  missing  in  INTERIM  statement 
INT04  Type  missing  or  illegal  in  INTERIM 
statement 

INT05  Right  paren  missing  in  INTERIM  statement 
ITEM01  ITFMOl  Name  missing  or  illegal  in  item  list 

LIBERR  LIR01  Left  paren  missing  in  library  call 

LIR02  Library  name  missing  or  illegal  in  FILE 
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MODULI  MODULI  Colon  missing  after  keyword  MODULE 
M0DUL2  M0DUL2  Mane  missing  or  Illegal  In  MODULE  statement 
PARERR  PAREPR  Tape  spec  parameter  missing  or  illegal 
QNMEPR  QMMERP.  Oualified  name  illegal 
RCFERl  RECF01  Record  format  missing  or  illegal 
RCFEF2  IIECF02  BLOCKS  I7-E  keyword  missing  in  record  format 
specification 

PECF03  Rlocksize  value  missing  or  illegal  in 
record  format  spec 

FCFER 3 RECF04  Record  size  value  missing  or  illegal  in 

record  format  spec 

RECITER  RECD01  Left  paren  missing  in  RECORD  statement 
RECD02  Right  paren  missing  in  RECORD  statement 
RPTERR  RPT01  Left  paren  missing  in  REPORT  statement 
PPT02  Keyword  REPORTJTNTRY  missing 
RPT03  Report  entry  name  missing 
RPT04  Right  paren  missing  in  REPORT  statement 
RPTNEK  PPTN01  Left  paren  missing  in  REPORTJTNTRY 
statement 

RPTN02  Right  paren  missing  in  REPORTJTNTRY 
statement 

SEMI  SEMI  Semi-colon  missing  at  end  of  statement 

SRCFL1  SRCFL1  Colon  missing  after  keyword  SOURCE  [FILES] 
SRCFL2  SRCFL2  Name  missing  or  illegal  in  source  file  list 

TAPERR  TAPE01  Left  paren  missing  in  TAPE  statement 

TAPE02  Right  paren  missing  in  TAPE  statement 


r 
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TAP.FL1 

TAPFL1 

Colon  missing  after  keyword  TAPOFT 

TARFL2 

TARFL2 

Name  missing  or  Illegal  in  TAPCET  file  list 

TLARFRP 

TLAP01 

Keyword  INT_l!AME  missing,  in  tape  label 

r 

description 

1 

TLAB02 

Internal  name  missing  or  illegal  in  tape 

J 

label  description 

TRUERR 

TPMER  1 

Left  paren  missing  in  TEPM  description 

] 

TRUER  2 

Right  paren  missing,  in  TERM  description 

: 

UNFECS 

UMP ECS 

Unrecognizable  statement 

VPLERR 

VO  LERI 

VOL_NAME  keyword  missing 

• ' 
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Encoding /Saving  routines 
NAME  STMT  WHAT  IT  POES 

SVASNM  76  Saves  assertion  name  in  assertion  storage  entry 

SVBLK  62,70  Saves  hlocksize  in  disk/tape  storage  entry 
SVCC  16  Encodes  character  code 

0-EBCDIC,  1 “BCD,  2-ASCII 

SVCOL  30  Saves  column  number  in  field  storage  entry 

SVD11NM  0 Saves  data  description  statement  name 

SVDEN  50  Saves  density  in  tape  storage  entry; 

SVDSK  53  Encodes  disk  statement  type  as  disk 

SVEACH  78,79  Saves  FOREACM  name  in  assertion  storage  entry 
SVFCN  77  Saves  function  name  in  assertion  storage  entry 

SVFPTP  28  Encodes  field  type 

0»character;  l“binary;  2“dec imal ; 3-numeric ; 
SVFILE  13  Encodes  file  statement  type  as  FILE 

SVFLD  27  Encodes  field  statement  type  as  FLD 

SVINCR  55  Saves  increment  in  disk  storage  entry 

SVINNM  36  Encodes  INTERIM  statement  type  as  INTP 

SVINTNM  47  Saves  internal  label  name  in  disk  storage  entry 

SVINTN  62  Saves  internal  label  name  in  tape  storage  entry 

SVKEY  16  Saves  key  field  in  file  storage  entry 

SVLAR  62  Encodes  label  type  in  tape  statement; 

0-none,  1-IBM_ST0,  2«ANSI_STI),  3-BYPASS 
SVLBNM  17  Saves  library  name  in  file  storage  entry 

SVLINE  29  Saves  line  number  in  field  storage  entry 


storage  entry 

SVORC  54  Encodes  organization  type  in  DISK  statement 

S=sequent ial ; 1=  ISAM  ; 

SVPAR  49  Saves  parity  in  tape  statement 

SVOTY  55  Saves  track  o'lantity  in  disk  storage  entry 

SVRCNM  15  Saves  record  name  in  file  description  storage  entry 


SVRCSZ  67,70  Saves  record  size  in  tape/disk  storage  entry 
SVRENM  34  Saves  report  entry  name  in  report  storage  entry 

SVRECF  68,70  Encodes  record  format  on  tape/disk  storage  entry; 
0-FIXED,  INFIXED  BLOCK,  2-VAPIABLE 
3-VARIABLE  BLOCKED,  4-VAP.IABLE  SPANNED, 

5-VARIABLE  SPANNED  BLOCKED,  6 -UNDEFINED 
S'/RLSE  55  Encodes  space  release  indicator  in  disk  storage  entry 
l=release;  0=no  release; 

SVRPT  34  Encodes  report  statement  type  as  RE.PT  storage  entry 
SVSF  78  Saves  source  name  to  assertion  in  ASSP.  storage  entry 

SVSRC  6 Saves  source  file  name  in  source  storage  entry 

SVSTFL  52  Sa  es  start  file  in  TAPE  storage  entry 

SVSTMM  16  Saves  storage  name  in  FILE  storage  entry 

SVTAB  33  Sets  tabulated  indicator  in  group  storage  entry 


m 
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SVTAPE 

45 

Encodes  tape  statement  type  as  TAPE 

SVTAR 

8 

Saves  target  file  name  in  target  storage 

entry 

SVTERM 

41 

Encodes  terminal  statement  type  as  TERM 

SVTG 

7D 

Saves  target  name  to  assertion  in  ASTC  storage  entry 

SVTMUK 

42 

Saves  tape  unit  number  of  tape  storage  entry 

SVTRK 

48 

Saves  number  of  tracks  in  TAPE  statement 

SVTRMKM 

43 

Saves  terminal  name 

SVTXSTP 

77 

Saves  text  of  assertion  in  assertion 

storage  entry 

(SVTX) 

SVUNIT 

54 

Encodes  disk  units  in  DISK  storage  entry 

SVEN  ITS 

65 

Saves  space  units  in  DISK  storage  entry 

SVVOL 

46, 

54  Saves  volume  name  in  disk/tape  storage 

entry 

A final  note  about  the  SAP  is  that  it  lists  all  the  source 
statements  in  the  order  that  they  are  submitted,  and  numbers  the 
statements  in  the  listing.  There  is  no  real  reason  to  reorder  the 
MODEL  statements  in  the  listing  because  the  non-procedural  nature  of 
MODEL  implies  no  special  significance  to  any  order.  As  seen  in  an 
example  of  a listing  later,  the  SAP  also  prints  various  headings  for 
readabil 1 ty. 
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4.2.4  The  String  Storage  and  Retrieval  Suh-System 

4. 2. 4.1  Introduction 

In  order  to  augment  the  SAFE  system  with  a general-purpose 
mechanism  for  storing  and  later  retrieving  source  language  strings, 
the  following  system  has  been  implemented.  Basically,  it  consists  of 
two  main  routines: 

(1)  STORR  for  storing  source  language  strings  collected  during  syntax 
analysis;  and 

(2)  RETRIEVE  for  accessing  previously  stored  source  language  strings, 
based  on  a variety  of  "keys." 

The  STORE  procedure  accepts  strings  which  are  formed  by  the 
subroutines  called  during  syntax  analysis.  It  stores  the  strings  in 
memory  which  we  call  "storage  entries"  while  building  "directory 
entries"  in  a directory  of  certain  names  designated  as  keys . By 
building  a directory,  the  strings  are  stored  "assoc iatively"  in  the 
sense  that  statements  can  later  be  retrieved  based  on  their  content. 
This  capability  is  crucial  to  a "non-procedural"  language  processor, 
since  the  statements  can  be  input  in  any  order. 

4. 2. 4. 2 The  Directory  and  Storage  Structure 

The  storage  entries  (the  strings  to  be  stored)  consist  of  two 
parts : 

(1)  the  key  names  to  be  entered  in  the  directory  which  include  the 
names  the  user  provided  in  the  MODEL  statements  for  naming  data, 
assertions,  etc.  These  are  the  names  by  which  we  may  want  to  retrieve 


information  later 


(2)  auxiliary  data  from  the  source  language  strings  including  the 
encoded  information  in  table  form.  This  information  is  not  used  as  the 
basis  of  retrievals. 

Each  storage  entry  will  contain  information  from  a given  MODEL 
statement.  They  will  appear  in  memory  in  the  order  in  which  they  are 
processed . 

The  directory  consists  of  an  entry  for  each  key  name.  Each 
directory  entry  points  to  the  first  storage  entry  containing  that  key 
name.  A linked-list  is  then  maintained  from  the  first  storage  entry 
with  that  key  name  to  other  storage  entries  containing  the  same  key 
name.  A "branch  and  bound"  binary  tree  structure  was  chosen  for  the 
directory  itself  to  make  tree  modifications  and  searching  for  key 
names  efficient.  That  is  the  first  key  name  entered  in  the  directory 
becomes  the  root  of  the  directory  tree;  the  next  key  is  entered 
"above"  or  "below"  it  in  the  tree  by  lexicographic  order;  etc. 

Each  directory  entry  has  the  following  form: 

H 1 4 + + 

I I I I I 

I Key  name  I ptr-to-f irst I up-pointer  | down-pointer | 


— ••  — 
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inhere 

"keyname"  Is  a string  of  (up  to)  10  characters  (padded  with  blanks) 
"ptr-to-f lrst"  is  a pointer  to  the  first  storage  entry  containing  the 
"key  name". 

"up-polnter"  and  "down-pointer"  are  pointers  to  other  directory 
entries,  whose  key  names  are  up  or  down,  respectively,  in  the 
lexicographic  sense. 


Hach  storage  entry  has  the  following  form: 

4 4-1 4 H 4-1 4 44- + 

I II  I II  II  I II  I 

|N  ||  name  1 | ptrl  ||  . . . ||  Name  n|  ptr  nil  ptr-to-data  | 

I II  I II  II  I 


| other  data  | 


where 

n^  is  the  number  of  key  names  in  the  storage  entry  string. 

Name  (1=1  to  n)  is  a pointer  to  the  next  storage  entry  with  the  same 
key  name. 

Pt r (i=l  to  n)  is  a pointer  to  the  next  storage  entry  with  the  same 
key  name. 

Pt r-to-data  is  a pointer  to  auxiliary  data  from  the  source  language 


1-/ ■/..  ... 


statement 
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Figure  4.7  depicts  an  exanple  of  three  storage  entries  and  a 
directory  consisting  of  only  three  entries,  X,  Y,  and  Z,  where  Y is 
the  directory  tree  apex.  Such  a structure  was  partially  motivated  by 
similar  ideas  in  the  "multi-list"  file  organization  [PRY66J. 

4. 2. 4. 3 Storage  Entries  Format  and  Tables  for  MODEL  Statements 

The  STORE  mechanism,  described  in  the  next  section,  is  called  by 
SAP's  storing  subroutines  to  store  the  MODEL  statements  for  retrieval 
(by  FvETRIEVE)  in  the  later  phases.  For  each  type  of  MODEL  statement, 
the  key  names  in  it  are  stored  in  its  storage  entry.  The  non-key 
information  in  the  MODEL  statement  (information  which  is  not  used  to 
specify  retrievals)  is  kept  in  description  tables,  which  are  connected 
(by  STORE)  to  the  corresponding  storage  entries  as  was  shown  above. 
Table  4.4  summarizes  the  internal  format  of  the  storage  entries  and 
the  corresponding  description  tables  for  each  type  of  MODEL  statement. 
The  left  column  in  this  table  depicts  each  prototype  MODEL  statement. 
The  first  name  in  each  entry  is  the  name  of  the  statement  being 
stored.  The  middle  column  shows  the  information  appearing  in  the 
corresponding  storage  entry  (with  the  pointers  omitted  due  to  lack  of 
space).  The  right  column  shows  the  additional  encoded  information,  if 
any,  from  the  statement.  The  key  names  beginning  with  a dollar  sign 
(S)  in  the  storage  entries  are  not  user-provided,  but  are  inserted  by 
the  system  for  its  own  information.  The  last  . name  in  each  storage 
entry,  for  example,  identifies  the  type  of  statement,  while  the  name 
beginning  with  a "$P"  identifies  the  parent  file  in  which  a data  item 
appears . 


<*  •'-V,  , , 


Figure  4-7 

Sample  Directory  and  Storage  Entries 
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4. 2. A. 4 The  STORE  Procedure 


The  STORE (S,D)  Procedure  has  two  parameters,  S and  D.  S is  the 
string  containing  the  key  names  which  are  to  be  stored  and  to  be 
entered  in  the  directory.  P is  a pointer  to  previously  built  auxiliary 
data  from  the  source  string.  The  latter  usually  is  an  encoded  form  of 
non-key  source  language  information. 

Algorithm  STORE  shows  the  storing  procedure.  Section  4.2.  3.  2 
already  depicted  the  data  structures  that  STORE  creates. 

STORE  receives  the  key  names  from  S and  creates  a storage  entry 
for  it  (Steps  1-3).  It  checks  if  they  are  in  the  directory  (Steps  4-5, 
subroutine  SEARCIIOIR ).  If  the  key  is  in  the  directory,  then  it 
follows  the  "pointer-to-f irst"  which  points  to  the  first  storage  entry 
with  that  name  (Steps  7-8).  The  array  of  strings  in  each  storage  entry 
is  scanned  until  the  key  name  is  found.  If  its  "next"  pointer  is  null 
(end-of-1 1st) , then  it  is  set  to  point  to  the  nevly  created  storage 
entry  (Steps  8-11).  If  it  is  not,  the  process  is  repeated  until  a null 
(end-of-1 1st)  pointer  is  found  (Steps  9-10).  If  the  current  key  name 
Is  not  found  in  the  directory,  it  is  entered  in  the  appropriate  spot 
in  the  lexicographical  position  in  the  directory  (Step  6,  sub-routine 
CREATF,_T>1R  ) and  the  pointer  in  the  directory  is  set  to  point  to  the 


154 


Algorithm  STORE  : The  Store  Procedure 

Parameters:  S«strlng  of  keys  to  be  stored; 
n«polnter  to  other  data 

(see  Section  4.2. 3. 2 for  diagrams  of  Data  Structures) 

[Subroutines  called:  CHECK_DIR,  CENERATEJENTRY] 

Step  1.  Count  #KEYS. 

Step  2.  Allocate  the  storage  entry  for  S (call  it  SE,  according  to  the 
format  shown). 

Step  3.  Connect  PTR_TO_DATA  in  SE  to  D. 

Step  4.  For  each  key  name,  perform  steps  5 through  11. 

Step  5.  If  key  exists  in  the  directory  (Algorithn  CHECK-DIP  ),  then  go 
to  step  7;  else  go  to  step  6. 

Step  6.  Create  a directory  entry  for  this  key.  (Algorithm  C.EEERATE- 
EHTRY  ) 

Step  7.  Let  DE*this  directory  entry. 

Step  8.  If  PTR_TO_FIPST  in  DE  already  points  to  a first  storage  entry 
with  this  key  name,  then  go  to  step  9;  else  go  to  step  11. 

Step  9.  Get  the  next  storage  entry  in  the  list. 

Step  10.  If  it  is  the  last  in  list,  then  go  to  step  11;  else  go  to 
step  9. 

Step  11.  Add  the  new  SE  to  the  list. 

Step  12. 


Return 
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newly  created  first  storage  entry  (Steps  7-8). 


4. 2.4.5  The  RETRIEVE  Procedure 


RETEIEVE(E,P,S,N,P)  Is  the  procedure  for  retrieving  desired 
storage  entries,  by  searching  through  the  data  structures  depicted  In 
Figure  4.7  and  Table  4.4.  It  Is  invoked  by  many  routines  described  in 
subsequent  phases  of  the  Processor.  It  has  five  input  parameters  as 
Indicated.  RETRIEVE  finds  all  the  storage  entries  in  which  the  given 
key  name  or  expression  of  key  names,  E,  appears  and  furthermore  checks 
whether  the  first  characters  of  data  associated  with  the  storage 
entries  match  the  string  D.  That  is,  RETRIEVE  finds  all  the  storage 
entries  with  keys  satisfying  the  logical  expression  E and  other  data 

H.  RETRIEVE  starts  its  search  at  directory  entry  S,  normally  the  root 

> 

node  of  the  directory,  and  it  returns  a list  of  pointers  P,  to  those 
storage  entries  which  satisfy  the  request  by  the  calling  program.  The 
number  of  storage  entries  satisfying  the  request  is  returned  in  11. 


The  logical  expression  E used  to  retrieve  strings  can  be  any 
boolean  expression  involving  "key"  names  or  names  in  the  MODEL 
statements  in  disjunctive  normal  form,  where  the  first  key  in  each 
term  is  non-negated.  For  example,  consider  the  following  statement  by 
a calling  program: 

CALL  RETRIEVE  (KEYS,  ".START,  N,P); 

KEYS  might  contain  the  string  value  'PRICE  & -QUAflTITY |EXTENT'  . This 
nakes  RETRIEVE  find  all  storage  entries  (which  c<*'respond  to  all 
statements  in  the  MODEL  specification)  in  which  PRICE  appears  and 
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QUANTITY  does  not  appear,  or  statements  In  which  EXTENT  appears.  The 
null  second  parameter  means  that  the  auxiliary  data  portion  of  each 
statement  is  immaterial.  RETRIEVE  would  then  start  its  search  and 
return  a list  of  pointers  in  P to  to  those  storage  entries  which 
satisfy  the  condition,  and  N would  be  set  to  the  number  of  such 
statements  that  satisfy  the  condition. 

Algorithm  RETRIEVE  is  shown  on  the  following  page.  An 
example  showing  the  retrieval  mechanism  to  retrieve  all  storage 
entries  with  key  names  "B"  and  "C"  is  given  in  Figure  4.7a.  The 
diagram  shows  in  parentheses  the  steps  that  correspond  in  the 
algorithm.  RETRIEVE  starts  by  getting  the  leading  key  name  of  the 
first  conjunct  (Step  1)  and  searches  the  directory  for  it  (Step  2).  If 
found,  it  puts  the  list  of  pointers  to  all  storage  entries  with  that 
name  in  a temporary  list  (Steps  3-7).  If  there  are  other  names  in  the 
conjunct  (Steps  10,14),  then  RETRIEVE  eliminates  the  pointers  in  the 
temporary  list  to  storage  entries  that  do  not  have  the  other  terms  in 
the  conjunct  (Steps  14-16).  If  there  are  more  conjuncts  in  the 
expression,  then  the  process  is  repeated  and  the  additional  pointers 
are  added  to  the  list  (Steps  12-13).  when  the  end  of  the  expression  is 
reached,  the  list  of  pointers  to  the  satisfying  storage  entries  and 
the  number  of  pointers  are  returned  (Steps  20-22). 


1J/ 

Algorithm  RETRIEVE  : The  Retrieve  Procedure 

Parameters:  I>logical  expression  string;  S-pointer 

to  beginning  of  directory  (input); 

P-llst  of  pointers  satisfying  E;  N«number  of 
satisfying  entries 

(see  Section  4. 2.3. 2 for  diagrams  of  data 
structures) 


Step  1.  Get  leading  key  name  K of  next  conjunct  from  E.  If 
no  more,  go  to  Step  22. 

Step  2.  Check  directory  for  K (standard  binary  tree  search 
in  subroutine  SEARCH-DIP  given  earlier). 

Step  3.  If  found,  then  go  to  step  4;  else  go  to  step  1. 

Step  4.  Set  PS  E-PT R_T 0_F I R S T (pointer  to  first  storage  entry 
with  K) 

Step  5.  Add  PSE  to  W list  (temporary  list*of  pointers) 

Step  6.  If  K in  PSE  storage  entry  points  to  another  storage 
entry  with  then  go  to  step  7;  else  go  to  step  8. 

Step  7.  Set  PSE  to  next  storage  entry  in  the  list,  go  to 
Step  5. 

Step  8.  If  end  of  E,  then  go  to  step  20;  else  go  to  step  9. 
Step  9.  Oet  next  symbol  in  E. 

Step  10.  If  symbol- '&'  then  go  to  step  14;  else  go  to  step 

11. 

Step  11.  If  symbol-' then  go  to  step  12;  else  error 
return. 

Step  12.  Add  list  of  pointers  in  W to  list  of  pointers  in  P 
without  duplication. 

Step  13.  Go  to  step  1. 

Step  14.  Get  next  symbol. 

Step  15.  If  symbol-"*'  then  go  to  step  16;  else  go  to  step 
18. 

Step  16.  (Case  of  conjoining  negated  term)  eliminate 

pointers  in  V to  storage  entries  which  also  contain  next  key 
name  in  E. 

Step  17.  Go  to  step  8. 

Step  18.  (Case  of  conjoining  non-negated  term)  eliminate 

pointers  in  W to  storage  entries  which  do  not  contain  next 
key  name  in  E. 

Step  19.  Go  to  step  8. 

Step  20.  Add  list  of  pointers  in  W to  list  of  pointers  in  P. 
Step  21.  Set  D-numher  of  pointers  in  P list. 

Step  22.  Return. 


m 


*v;  t mm 


159 


4.2.5  Components  of  a Ceneral  System  for  Statement  Analysis,  Storage, 
and  Retrieval 

The  SAPC,  the  lexical  analyzer,  and  the  storage  and  retrieval 
procedures  form  a self-contained  suh-system  that  has  been  implemented 
and  applied  here  to  several  tasks:  analysis  of  MODEL  statements  for 
syntactic  and  local  semantic  correctness,  storage  of  MODEL  statements 
In  a simulated  associative  memory,  and  a facility  for  later  retrieval 
of  stored  statements  for  subsequent  phases  of  the  Processor.  However, 
this  collection  of  procedures  in  itself  forms  a general-purpose  sub- 
system which  can  be  used  for  processing  languages  other  than  MODEL. 
Nothing  in  this  sub-system  really  depended  on  the  nature  of  the  MODEL 
language.  With  the  exception  of  the  .lexical  tables  which  might  need 
adjustment  for  another  language,  the  lexical  analyzer,  SAPC,  STORE, 
and  RETRIEVE  could  be  applied  directly  as  a general  package  for  first 
pass  processing  of  language  statements. 

4.2.6  Cross  Reference  and  Attribute  Report 

A useful  product  of  the  Syntax  and  Statement  Analysis  Phase  is  a 
cross-reference  report,  produced  by  a cross-reference  program  (XPEE) 
whose  input  is  the  encoded  and  stored  MODEL  specification.  The  XPEF 
report  provides  an  alphabetical  listing  of  all  the  names  provided  by 
the  user,  and  some  of  the  reserved  special  names  (such  as  CHOICE).  For 
each  name,  the  report  provides  the  statement  number  in  which  the 
entity  was  described,  the  statement  numbers  of  statements  in  which  it 
is  referenced,  and  the  attributes  or  other  known  characteristics 


- 


repardinp  the  name 


For  example,  if  field  X is  described  in  a piven  statement  and  is 
used  in  various  other  MODEL  statements,  such  as  in  assertions,  the 
cross-reference  list  would  provide  the  original  statement  number  in 
which  it  is  described,  a list  of  all  the  field's  attributes  as  well  as 
the  names  of  the  file  or  files  in  \diich  it  is  a menber,  and  a list  of 
statement  numbers  which  reference  the  p,iven  field  name. 

An  example  of  a typical  cross-reference  report  appears  in  Fip,ure 

4.8. 

The  cross-reference  report  is  produced  by  the  XRF.F  module.  It 
produces  the  report  by  traversinp  the  directory  and  producing  each 
line  by  successive  uses  of  RETRIEVE  to  get  the  corresponding 
references.  A bubble-sort  is  used  to  alphabetize  the  listing  (in  a 


subroutine  naned  AhPHDIF, ) 
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CROSS  REFERENCE  AND  ATTRIBUTE  REPORT 


NAME 

DESCRIPTION 

STATEMENT 

ATTRIBUTES 

REFERENCES 

BALANCE 

13 

FIELD, CHARACTER, 
FIXED, IN  TILE 
CUST 

7,41,43 

CHOICE 

RESERVED  WORD 

21,29,  31,32,  38 
22,25 

CURT 

2 

FILE, SOURCE, 
SORTED 

6,8,9, 10 

CUSTDISK 

7 

DISK  NAME 

C 

18 

CROUP, 4, IN  FILE  X 

22,25 

RALDUE 

34 

ASSERTION 

NAME 

15 

FIELD, CHARACTER, 
IN  FILE  X 

39,49 

NAME 

20 

FI ELD, CHARACTER, 
FILE  Y 

51,46 

Z 

UNDEFINED-ERROR 

52,59 

FIGURE  4.8 

EXAMPLE  OF  CROSS-REFERENCE  AND  ATTRIBUTE  REPORT 
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4.3  Analysis  of  MODEL  Specif ication 
4.3.1  Introduction  and  Background 

This  phase  of  the  MODEL  Processor  deals  with  the  analysis  of 
MODEL  specifications  by  the  use  of  graphs.  It  describes  an  application 
of  graph  theory  to  the  analysis  of  MODEL  specifications  and  to  the 
generation  of  seauenced  code  fron  it.  'Jhile  graph  theory  has  been  used 
in  various  computer  applications  in  recent  years  (e.g. [N1IH71 ,LAM65] ) , 
the  analysis  of  information  relationships  and  automatic  sequencing  and 
generation  of  code  by  means  of  graphs  have  heen  novel  and  successful 
techniques  here.  This  introductory  sub-section  presents  and 
exemplifies  the  background  and  terminology  involved  in  this  phase,  and 
describes  the  graphs,  matrices,  and  other  data  structures  that  are 
built  from  a MODEL  specification. 

Section  4.3.2  provides  an  overview  of  the  processes  involved  in 
this  phase,  and  Section  4.3.3  discusses  them  in  greater  detail.  In 
order  to  exemplify  the  algorithms  and  data  structures  used,  a sample 
problem  is  presented  below  and  described  using  the  MODEL  language.  Its 
processing  is  traced  throughout  each  of  the  sub-phases.  The  sample 
problem  used  is  a small  subset  of  the  department  store  sale  problem 
(DFPSALF.)  of  Chapter  3.  '/hile  the  problem  given  in  Chapter  3 presents 
a more  realistic  real-world  situation,  the  smaller  suhset  chosen  is 
traced  here  because  it  is  not  overly  complex,  yet  has  enough  features 
to  exemplify  the  results  of  the  algorithms. 
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As  has  been  shown  in  the  previous  chapter,  the  statements  of  a 
•mPEL  specification  consist  of  a series  of  descriptions  of  the 
following: 

(1)  files,  each  of  which  is  designated  as  a source  file, 
target  file,  or  both; 

(2)  components  of  each  file;  i.e.  records,  groups,  fields  and 
the  physical  storage  medium,  as  well  as  dynamic  assertions 
for  data-dependent  description; 

(3)  the  inter-relationships  of  the  files; 

(4)  assertions  giving  logical  and  arithmetic  relationships 
between  the  various  data  items. 

A small  sample  set  of  MOPEL  statements  is  provided  in  Figure  4.9 
for  discussion  purposes.  This  example  is  a subset  of  the  DEPSALE 
problem  in  Chapter  3,  and  is  used  here  and  in  subsequent  sections  as  a 
vehicle  for  explaining  the  various  algorithms.  The  smaller  example 
(referred  to  as  MINSALE)  describes  a nodule  whose  input  is  a sale 
transaction  file  (consisting  of  a customer  number,  stock  number,  and 
quantity  desired)  and  an  inventory  file  of  items  (consisting  of  a 
stock  number,  price,  and  quantity  on  hand).  The  output  of  the  module 
being  described  is  a sale  slip  report  (consisting  of  the  customer 
number,  stock  number,  and  charge)  and  the  updated  inventory  file  with 
the  new  quantity  on  hand  after  the  sale.  The  original  DEPSALE  problem 
has  other  fields  in  each  of  these  files,  plus  other  auxiliary  files, 
but  these  are  not  crucial  to  the  current  discussion. 
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Flgur*  4.9s.mpU  S«t  of  MODEL  StACemenca 


MIHSALE  MOOUlE  specification 


1 (3}  MODULE:  MlNSALEl 

2 So  "MCE  files:  SALCTRAilMVEM 

3 target  files:  saleslip.  ih/em 


file  descriptions: 


DESCRIPTION  of  SAlET.TA  1 FILE 


# 

■»  N) 

SA.ETf.ru  is  FIlCIKCCORO  IS  SAlEKEC. STORAGE 

a 

5 /’lb) 

SalCREC  is  RECORD  (CL^Ta  . sTCC*a  . OUa'IT I TY  » : 

6 {?!) 

C U s T l*  IS  F ILIlMCHA.I  (5)1: 

7 (31) 

STjCKk  IS  FILL- It  1AMI 7) ) : 

_u 

o bn 

OUAMTITt  IS  FIELCICHAKI 3) ) 4 

* 

9 I'D 

SalEOECK  is  card; 

OESCR  1 PT I Oil  OF  IlivCl. 


10  (</ Tj  IliMEll  IS  FILEIPECCOO  IS  luvaEC.  STORAGE  IS  I.jVOISk.  KEY  IS  STOCK"! 
llh'u)  lil'.'hCc  IS  PCCC'tJI  STCC<*  .SALPRICE  .OOh)  i 
12("/iOj  S T C C K fc  IS  FICLHICMAh  ( 7)  1 : 

13  SALP.’.ICC  IS  riEL3<!':u"'EK!CtSn  : 

Is  OOH  IS  FICLJli.v— E'tlCIS!) : 

1S&Z)  Irn'DlSf  IS  ClS'U  5PCA  lIZATIOIl  = ISV  .VARIABLE. •"AX.DLOCKSIZErSaOO* 
15  k/>X.MCC0I!'uSUL  = 1 T<  VOL.'IA  ,'C  = l,|VV/OL  . j:  1 1 T = zi  1m  ) i 


DESCRIPTION  OF  SALESLIP  REPORT 


16  (l?)  S/.LLSLIP  is  P.EPO'-.TCREPOhI-EUTRT  IS  SLIPREC): 

17  (jyj-'j  SL  t PfJEC  IS  REF  Ji:T_E  '.'T  ?T < CUST'! , STCCKu  .ChA  «GE  ) t 

16  (1*1  Cos  I s IS  FlCLLIC'lvmi  I : 

19  stock-  IS  FlELLIClA.ItH  II  : 

20  Cl'S)  CHARbC  IS  FICLDINU  lEHICtO! ) I 


utekfile  .iClat U-. ships 


n VHflMM 


> 

«(*» 

21 

22 

23 

InrCHfrLC  RELATI ?•  SHIPS: 
tr;  iv: 

cCURCE:  SALE THAI.. STICK*  1 
target:  POi.,Ts;i.nLU.inwnec; 

“POINTCR.GLC.  l,,vNCC:SALET.RAr.. STOCKIN'  1 

• 

/• 

•/ 

/• 
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The  statement  numbers  down  the  left-hand  side  are  MODEL  statement 
numbers  printed  by  the  Processor,  while  the  numbers  In  parentheses  are 
the  corresponding  dictionary  node  numbers  In  alphabetical  sequence  to 
be  described  later. 

The  preparer  of  the  MODEL  specification  gives  each  entity  in  his 
statements  — file,  field,  assertion,  etc.  — a symbolic  name.  In  this 
phase,  each  name  is  related  by  the  Processor  to  other  names  in  one  of 
several  ways.  Hierarchical  relationships  exist  when  one  data  item 
contains  another,  such  as  when  a file  contains  a record,  a record 
contains  a field,  etc.  A pointing  relationship  exists  when  a field  of 
a record  in  one  file  points  to  a record  of  another  file.  A value 
dependency  relationship  exists  between  a field  and  an  assertion,  for 
example,  when  the  value  of  the  field  is  a source  variable  of  the 
assertion;  likewise,  there  can  be  a value  dependency  of  a target  field 
of  an  assertion  on  the  assertion. 

In  all  of  these  precedence  relationships , the  former  in  some 
sense  must  precede  the  latter  and  is  said  to  be  a predecessor  (also 
known  as  a precedent  ) of  the  latter,  while  the  latter  is  a successor 
(also  known  as  a direct  descendant  or  dependent  ) oF  the  former.  The 
various  types  of  precedence  relationships  that  are  implicit  in  or 
deduced  from  a MODEL  specification  are  summarized  in  Table  4.5.  Each 
type  of  precedence  relationship  has  a corresponding  predecessor  and 
successor  type.  The  types  of  precedence  relationships  will  have  direct 
implications  on  the  program  to  be  generated.  For  example,  a record 
must  be  read  before  any  of  its  component  fields  can  he  used.  A field 


167 


3 73 


ft  3 


e 

ft  3 
U 

ft.  ft- 
X 

u 


c 

3 01 
•o  ft. 
3 >N 
O H 
« 
if 
ft- 


3 

3 - 

3 

73 

S Jo 

2 §2 

Ck  Z^ 


« 

e 

ti 

«• 

3 

3 

a 

i-4 

3 

9 

1 

9 

3 

3 

C 

X 

3 

X 73 

Li 

O 

73 

o 

^4 

3 

^4 

9 

3 

LI 

3 

ft. 

Li 

L- 

0 

U 

Li 

u 

O 

ft 

c 

0 

£ 

O 

O 

3 

•4 

o 

M 

• 

3 

i* 

O 

u 

3 

•4 

3 

3 

3 

Si 

3 

C 

3 

o 

l4 

3 

U 

3 

i4 

3 

Li 

£ 

C 

o 

LI 

^4 

3 

Li 

P-4 

3 

3 

ft 

— - 

ft. 

c 

3 

ft. 

CJ 

3 

o 

ft. 

3 

X 

0 

3 

£ 

o 

Li 

X 

CJ 

3 

LI 

£ 

3 

u 

LJ 

o 

o 

3 

3 

3 

3 

>4 

9 

O 

3 

c 

o 

T3 

3 

9 

Li 

3 

£ 

o 

• 

3 

3 

3 

« 

X 

ft 

u 

3 

1-4 

3 

14 

'Ll 

Lt 

00 

U4 

c 

3 

u 

3 

O 

o 

u 

0 

9 

Li 

3 

»-4 

u 

3 

L4 

3 

Li 

3 

o 

•3 

T~t 

o 

3 

o 

3 

• «. 

U 

0 

3 

U4 

X 

3 

«4-l 

3 

3 

3 

c 

3 

3 

O 

3 

3 

3 

3 

Li 

3 

L- 

0 

LI 

3 

3 

Li 

3 

3 

3 

0 

3 

3 

*^- 

•H 

LI 

3 

9 

JP 

3 

O 

CO 

O 

O 

3 

CJ 

O 

Li 

3 

3 

3 

O 

3 

ft 

3 

3 

L 

3 

3 

3 

3 

L- 

•4 

tJ 

3 

3 

ft 

X 

*3 

3 

73 

3 

*3 

3 

»-4 

T3 

^4 

3 

3 

O 

3 

O 

3 

3 

3 

ft. 

14 

3 

3 

73 

Li 

O 

3 

Li 

3 

W 

-C 

3 

X 

o 

U 

X 

o 

C 

ft. 

3 

•w 

ft- 

3 

ft- 

Li 

3 

3 

3 

ft- 

Li 

Li 

ft 

3 

as 

a 

§ 

l 

3 

O 

<L4 

3 

a 

O 

•3 

Li 

ft. 

X 

O 

to 

0 

3 

3 

3 

3 

3 

O 

O 

00 

CJ 

c 

■ 4 

Li 

3 

Li 

c 

Li 

3 

o 

(•] 

O 

ft. 

u 

1-1 

3 

3 

l4 

~1 

3 

3 

c 

O 

o 

Li 

Fl 

3 

Li 

Li 

1-4 

3 

X 

ft. 

3 

o 

C 

O 

3 

3 

-r4 

D 

3 

1-4 

Li 

3 

Li 

Li 

c 

3 

CL  ^ 

• 

c 

C 

O 

3 

3 

73 

3 

•9 

o 

C 

o 

3 

£ 

3 

O 

X 

u 

o 

*— 4 

l4 

3 

3 

M 

3 

0 

■w* 

Li 

T3 

X 

Li 

a 

o 

Li 

o 

Li 

Li 

3 

c 

3 

c 

L- 

3 

X 

3 

Li 

Li 

Lt 

• 

3 

OP 

3 

3 

3 

Li 

c 

3 

•H 

3 

£ 

£ 

-9 

3 

3 

3 

3 

3 

Li 

3 

- 

3 

£ 

< 

i4 

a 

£ 

TJ 

-r4 

O 

LI 

3 

3 

Li 

3 

1—4 

rH 

o 

3 

r- 

i 

3 

£ 

4-s 

3 

ft. 

3 

Li 

i4 

E 

Li 

3 

a 

t4 

X 

PC 

C/5 

4-1 

H 

3 

3 

>4 

ft- 

3 

Li 

X 

X 

3 

c 

H 

X 

3 

3 

i 

Li 

3 

3 

3 

Li 

£ 

3 

c 

l4 

3 

£ 

3 

C 

3 

3 

•-4 

cu 

X 

3 

3 

•3 

a 

£ 

LI 

LI 

C 

X 

1-4 

3 

W 

Li 

3 

3 

c 

l4 

3 

3 

Li 

00 

3 

X 

3 

<3 

cn 

3 

3 

3 

L- 

"3 

a 

3 

3 

ft. 

«—» 

Li 

3 

i4 

^4 

3 

CL  -ft 

3 

•r— 

3 

LI 

Li 

••4 

3 

3 

£ 

o 

'Ll 

Li 

c 

U4 

3 

O 

Li 

c 

3 

c 

3 

9 

3 

£ 

o 

Li 

o 

3 

3 

£ 

3 

O 

o 

3 

n 

O 

£ 

3 

c 

3 

3 

Li 

00 

LI 

L. 

JZ 

3 

LI 

3 

Li 

o 

L. 

ft. 

o 

3 

Li 

3 

k. 

Q 

O 

co- 

C 

3 

44 

3 

3 

X 

rn 

m 

Li 

L- 

c 

LJ 

3 

(44 

3 

O 

« 

T3 

U 

o 

3 

<— 1 

1—4 

-3 

X 

L 

3 

3 

•^4 

U 

-H 

9 

c 

3 

3 

0 

3 

D 

T3 

0 

73 

Li 

i4 

O 

00 

r— 1 

3 

C 

-a 

Li 

1-4 

3 

o 

0 

— - 

Q 

i-i 

3 

3 

3 

C 

00  73 

3 

-r4 

«3 

ftp 

>-/ 

3 

3 

— . 

3 

•H 

C 

p-4 

OP 

c 

Li 

3 

'Ll 

3 

*— 4 

3 

1-1 

3 

« 

X 

3 

< 

3 

3 

3 

l4 

- 

3 

O 

*3 

a 

LJ 

9 

ft. 

O 

ft- 

3 

LI 

Li 

H 

Li 

3 

3 

3 

»—• 

1-4 

c 

3 

3 

c 

4“N 

U 

3 

1-4 

i4 

o 

O 

•4 

3 

3 

Z5 

••4 

O 

X 

o 

ft 

ft. 

o 

3 

ft- 

£ 

ft- 

Li 

3 

«3 

H 

r-4 

1 

3 

3 

3 

O 

O 

T3 

X 

•iL 

-r4 

o 

x 

X 

Li 

X 

Li 

c 

o 

3 

CJ 

Li 

-*4 

CJ 

•^4 

3 

u 

O 

L- 

3 

CJ 

c 

U 

*9 

3 

3 

3 

00 

14 

3 

•r4 

C 

3 

3 

L 

Li 

^4 

*3 

1-4 

3 

3 

O 

3 

3 

ft. 

C 

a 

ft. 

•«4 

3 

•u 

Li 

X 

3 

£ 

3 

X 

= 

ft] 

ft. 

L4 

■o 

iH 

1 

rH 

rM 

CM 

CM 

PO 

C 

£ -< 


V-  73 
3 »-< 
3 3 

C *H 

H4  ft. 


L.  O, 

o o4 


(A  3 


3 -*4 
3 •— 

Of  o 

73  X 
Of  £ 

£ H 

ft- 


3 00 

c 

C -*4 
O a 
X 


Li  X 

3 

•a 


en  3 


O 
a 
at 
3 3 
CL 

X <0 


c o 


3 i4 


3 


-o 

li  0) 
£ 3 li 

•H  {JO  c 
O LI  -H 
ft-  <0  O 
: 4J  aJ 


00  c 
c o 


o a> 

ft-  3 


•3  > 

3 

Li  *9 

O 

(0  Li 


4)  ft 

3 ft 
4)  4» 
•&  ‘ 


4)  O 


Li  3 
ft-  ft 


CL  - 
-4  W 
Li  ft-  3 
3 < C 
(0  H 3 
4»  e 

73  - 4) 

„ X LJ 
E C/5  <0 
3 M Li 
•*■4  Q « 
•3  w 
4) 

£ X 3 


4)  a- 

00  o 


Li  C Q 
O O 0C 

3 -r4  < 

CO  Li  o 


3 CL 


£ 
<0  co 
14  C 
*3  O 
4J  i4 
S Li 


• 0 

§* 


3 

*4  *3 

LUC 

U 41  o 

L 60  O 

.-4  U 
0.(0® 
X Li 
3 L» 


X i4 

o J 


X *3 
3 4) 


X <0 


•H  Li  CO 


3 O c 
c o 

C 9 -3 

o 'Ll  3 


Li  3 *3 
Li  C 
4)  CO  O 
4)  3 


co  co 


<33 


3 3 

C 3 

o c 


3 


u 73 

•H  c 

•3  3 
C CL 
O 3 
CJ  -3 


ft  3 *3 
-4.0  C 

Li  X 
O X 


3 O C 
3 O 
O 3 
3 0 3 
73  V-  Li 
3 3 3 
L O H 

pl  as  a. 


C/3 

ft] 

ft. 


ft] 

CJ 

z 

s 

ft] 

CJ 

s 

ft- 


Ll  o 
3 O 
00  3 
Li  CO  00 
3 3 3 
H -4 
C ’Ll 
X O 


3 

03 

s 


£5%  T-,:^3»V 


168 

pointing  to  a keyed  record  must  he  available  before  the  record  being 
pointed  to  can  be  accessed.  A field  which  is  a source  or  input  to  an 
assertion  must  be  available  and  attain  a value  before  invoking  the 
procedure  embodying  the  assertion.  A field  which  is  a target  or  output 
of  an  assertion  is  only  available  after  the  procedure  is  called.  These 
and  other  requirements  of  the  program  to  be  generated  are  implied  by 
the  precedence  information  conveyed  in  a "directed  graph"  or  "weighted 
adjacency  matrix"  as  described  below. 

The  entire  aggregate  of  precedence  relationships  in  a MODEL 
specification  can  be  represented  pictorially  by  a directed  graph. 

Formally,  a directed  graph  is  a pair  <M , A > : a set  of  nodes 
N“{N 1,N2, . . . ,Mn>  and  a relation  A,  i.e.  a set  of  ordered  pairs 
("arrows"  or  "arcs")  (A1,A2, . . . , Ap > where  each  Ai  is  an  ordered  pair 
(flj.Nk)  representing  an  arrow  from  node  Nj  to  node  f’k.  In  other  words, 
A is  a relation  on  !I  x H.  Each  node  may  have  0,  1,  or  more  arrows 
emanating  from  it. 

A weighted  directed  graph  is  a directed  graph  where  each  arrow 
(N j , Nk ) from  node  j to  node  k is  a member  of  one  of  a set  of  different 
types  of  relations  {P.  1,R2, . . . ,Rq  ). 

Weighted  directed  graphs  are  used  to  represent  precedence 
relationships  in  MODEL  statements  because  of  the  different  types  of 
relationships,  as  described  earlier.  An  example  of  a weighted  directed 
graph  appears  in  Figure  4. 10,  which  corresponds  to  the  example  of 
Figure  4.Q.  Each  node  of  this  graph  represents  the  name  of  one  of  the 
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entities  in  the  MODEL  statement,  including  files,  records,  groups, 
fields,  assertions,  etc.  Each  node  has  0,  1,  or  more  arrows  emanating 
from  it  pointing  to  successor  nodes;  l.e.  to  nodes  to  which  it  is 


precedent.  Such  a graph  is  called  a directed  graph  or 


because 


each  arc  or  arrow  has  an  arrowhead  or  direction  to  it.  Furthermore, 
since  there  are  various  types  of  arrows  in  the  digraph  representing 
the  various  type  of  precedence  relationships,  this  is  a weighted 
digraph. 


The  numbers  over  the  nodes  of  the  digraph  are  the  node  numbers  of 
the  alphabetized  dictionary  (whose  creation  is  to  be  described 


further,  later).  Generally,  each  MODEL  statement  of  Figure  4.9 
corresponds  to  one  node  of  Figure  4.10.  The  numbers  in  parentheses  in 
Figure  4.9  showed  the  correspondence  between  the  MODEL  statement 
numbers  and  the  node  numbers  of  the  alphabetized  dictionary.  The 
exceptions  of  the  one-to-one  correspondence  are  the  following: 

(1)  Tiles  that  are  both  input  and  output  (such  as  INVEU  in 
the  example)  as  well  as  their  component  records,  groups,  and 
fields  are  described  only  once  in  MODEL,  but  become  two  nodes 
in  the  digraph  — one  for  the  "old"  or  source  data  and  one 
for  the  "new"  or  target  data. 

(2)  The  list  of  source  and  target  files  in  the  header  of  the 
MODEL  specification  do  not  correspond  to  any  node  in  the 
digraph  because  the  file  statements  themselves  correspond  to 
the  nodes  for  files. 

(3)  Special  names  in  MODEL,  such  as  POIMTEP  names,  EXIST 
names,  etc.,  are  not  described  explicitly  by  the  MODEL  user, 


but  are  used  only  in  context.  However,  in  the  digraph,  such 
special  names  do  correspond  to  nodes  and  have  successors, 
predecessors,  etc. 


There  are  a number  of  non-pictorial  representations  of  digraphs, 
which  can  be  found  in  many  standard  textbooks  [BER73].  One  such 
formalization  is  called  the  adjacency  matrix  of  a digraph.  An 
adjacency  matrix.  A,  corresponding  to  a digraph  <N,R>  of  n nodes  and 
one  relation  R,  is  an  n x n matrix  defined  as  follows: 

Aij  = 1 if  (Nj.Mk)  is  in  R;  0 otherwise 


In  order 

to 

distinguish 

between 

the  different 

types  of 

relationships 

that 

may  exist 

between 

two  nodes  of 

the  digraph. 

however,  a weighted  ad jacency  matrix  is  used.  It  has  a zero  everywhere 
that  the  adjacency  matrix  does,  but  has  a number  from  1 to  7 giving 
the  type  of  relationship  instead  of  the  adjacency  matrix  entry  of  "1". 
The  distinction  between  the  different  types  of  arcs  in  the  digraph  by 
use  of  these  codes  from  1 to  7 is  used  in  later  phases  of  analysis  of 
this  matrix.  Formally,  the  weighted  adjacency  matrix  is  defined  as 
follows : 

Mij=k  if  (Nj,Nk)  is  in  relation  Rk;  0 if  in  no  relation 
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The  weighted  adjacency  matrix  for  the  MODEL  example  of  Figure  4.9 
and  for  the  corresponding  digraph  of  Figure  4. 10  is  Riven  in  Figure 
4.11.  The  node  names  are  alphabetized  and  numbered  down  the  left-hand 
side.  The  numbers  to  the  right  of  the  name  are  the  original  MODFL 
statement  numbers  from  which  these  nodes  are  taken,  as  explained  in 
the  previous  section.  Entries  in  this  matrix  are  either  "0", 
indicating  that  there  is  no  relationship  between  the  row  and  column  of 
the  intersection,  or  are  a code  from  1 to  7 representing  the  type  of 
relationship.  The  relationship  codes  of  the  weighted  adjacency  for 
MODEL  are  exemplified  in  Table  4.6.  These  codes  correspond  to  the 
relationship  types  already  discussed,  and  the  examples  are  from  the 
same  sample  problen.  If  Mij*k,  the  code  in  the  left  hand  side  of  Table 
4.6,  then  Mi  is  related  to  NJ  in  the  manner  shown  in  the  middle 
column,  with  the  examples  appearing  in  the  third  column. 

Py  showing  predecessor  and  successor  relationships,  such  a 
weighted  adjacency  matrix  conveys  all  the  precedence  information  of  a 
MODEL  specification.  Mote  that  in  Table  4.6  hierarchical  relationships 
"l"  and  ''2"  are  reversed  in  direction  because,  for  example,  a record 
of  an  input  file  must  be  read  before  its  component  groups  and  fields 
are  available,  while  the  record  of  an  output  file  must  be  written 
after  its  component  groups  and  fields  attain  a value.  For  the  same 
reason,  the  arrows  emanating  from  nodes  representing  fields  in  output 
files  were  opposite  in  direction  of  those  of  input  files  in  the 
pictorial  digraph. 
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Precedence 
N um  be  r 


RELATIONSHIP  TYPE 


1 HI  err. rch  I cal  source 

node  I I;  an  Input 
f 1 1 0/  record,  or 
group  of  an  input  file 
and  con  la  ins  node  j as 
a sub-component 

2 Hierarchical  target 

node  I Is  a record, 
group  or  field  of  an 
output  file  and  Is  con- 
ta 1 ned  1 n node  j (its 
parent  group,  record, 
or  file) 

3 Explicit  Dependency 

node  I 1 s an  cxpl I c I t 
source  of  node  j by 
virtue  of  a user 
assertion  (latter  Is 
target  of  former) 

4 Implicit  Dependency 

node  I Is  an  impli- 
cit source  of  node  j 
due  to  Implicit  fac- 
tors explained 
later 


5  Pointing  Relationship 
node  i Is  a pointer 
to  node  j (a 
record  name ) • 


6 


Media  „ . „ . ,, 

Re  1 at  I onsh  I ps 

node  I I s a f i 1 e 
name  stored  on  a 
medium  whose  name 
is  In  node  j 


7 Conditional  Relationship 


EXAMPLE 


row  of  SALEREC  and 
column  of  SALETRAN.CUST# 
has  a 1 because  the  former 
contains  the  latter 


row  of  SALESUP. CHARGE  - 
and  column  of  SLIPREC 
has  a 2 because  the 
former  Is  contained 
in  the  latter 


row  of  QUANTITY  and 
column  of  CALCCHRG  has  a 
2 because  the  former 
Is  a source  of  the 
assert  I on 


row  of  OLD. STOCK#  and 
column  of  NEW, STOCK# 
has  a 4 because 
there  will  be  an  impli- 
cit rule  to  this  effect 


row  of  POINTER. I NVREC 
and  column  of  I NVREC 
has  a 5 because  the 
former  points  to  the 
latter 


row  of  INVEN  and 
column  of  INVDISK 
has  a 6 because 
the  former  Is  stored 
on  the  latter 

None  in  this  Example 


Table  4.6 illustration  of  Precedence  Relationships 
of  Table  4.5  for  Matrix  of  Figure  4.11 
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All  such  precedence  information  is  built  into  the  matrix  and 
analyzed  in  subsequent  sections. 


i 

i 

j 

1 
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4.3.2  Overview  of  Sub-phases  in  Network  Creation  and  Analysis 

The  digraph  of  a set  of  MODFL  statements  and  its  representation 
as  a Weighted  Adjacency  Matrix  is  a crucial  factor  in  the  MODF.L 
Processor's  ability  to  sequence  operations  and  to  detect  many 
inconsistencies  and  incomplete  specifications  that  a user  might 
submit.  Table  4.7  shows  a summary  of  the  nine  steps  or  suh-phases 
involved  in  the  creation  and  analysis  of  the  matrix  representation  of 
the  digraph  (or  "network").  It  summarizes  the  tasis  of  each  step  and 
the  relationships  for  which  each  step  searches.  The  nine  suh-phases 
themselves  are  described  in  greater  detail  in  sub-sections  4.  3. 3.  1 
through  4.3. 3. h.  The  process  is  begun  by  first  creating  a dictionary 
of  names  that  is  to  correspond  to  node  numbers  of  the  matrix  (Sub- 
phase 1,  Section  4.3. 3.1).  Creation  of  the  matrix  (Sub-phase  7, 
Section  4.  3.  3. 2)  and  entering,  the  various  precedence  relations  within 
it  are  dealt  with  next  (Sub-phases  3 through  7,  Sections  4. 3. 3.  3 
through  4.3.3. 7).  The  last  two  steps  deal  with  more  graph  analysis 
(Section  4.3.  3.  R)  and  cycle  detection  (Section  4. 3. 3.9). 

One  of  the  major  tasks  during  this  entire  phase  is  detecting 
logical  errors  and  reporting  them  to  the  user.  In  parallel  to 
searching  and  entering  precedence  relationships  in  the  weighted 
adjacency  matrix,  certain  kinds  of  logical  errors  are  detected,  and 
messages  are  sent  to  the  user.  Further  error  analysis  takes  place 
after  the  Processor  constructs  the  matrix.  A summary  of  the  error 
conditions  that  are  searched  for  by  each  of  the  nine  sub-phases  is 
summarized  in  Table  4.7a.  This  table  also  refers  to  the  error  messages 
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Step  Name 


Summary  of  Tasks  and/or 
Relationships  Searched 


1 Creating  Dictionary 
(CRDICT) 


Creates  a dictionary  of  all  names 
assigning  a "node"  number  to  each 


2 Creating  Weighted 
Adjacency  Matrix 
(CRADJMT) 


Creates  n x n weighted  adjacency 
matrix  (Initialized  to  zeros) 
whose  rows  and  columns  correspond 
to  the  dictionary 


3 entering  Hierarchical  Searching  for  hierarchical 
relationships  relationships  between  a parent 

(ENHRREL)  and  descendant  data 


4 Entering  Explicit 
Value  Dependencies 
(ENEXDP) 


Searches  for  explicit  value 
dependency  relationships  given 
by  assertions 


5 Entering  Conditional 
Value  Dependencies 
(ENEXDP) 


Searches  for  explicit  value 
dependencies  with  a conditionally 
completed  node 


f)  Finding  Implicit 
Predecessors 
(FNDISRC) 


Searches  for  implicit  predecessor 
to  nodes  with  no  explicit 
predecessor 


7 Entering  Pointing 
relationships 
(ENPTREL) 


Enters  pointing  relationships 
between  pointer  names  and  records 


P Graph  Analysis 
(AM ANAL ) 


Analyzes  the  weighted  adjacency 
matrix  to  ensure  that  certain 
error  conditions  do  not  exist 
(See  Table  4. 7a) 


n Cycle  Detection 
(CP.PATHS,  CYCLES) 


Creates  path  matrix  f>  searches 
for  possible  cycles 


Table  4.7 

Steps  in  Network  Creation  and  Analysis 


~ n t 


Step  Name 


Condition 


Msg#  f< 
Fxanples 
Frror  Tab. 4. 6c 


1  Creating  a Dictionary 
(CRDICT ) 


I 


2 Creating  the  Weighted 
Adjacency  Matrix  (CRADJMT) 

3 Entering  Hierarchical  Multiple,  contradictory 

Relationships  descriptions  of  data  name. 

(ENHRREL)  missing  description  of 

a data  descendant 


4 Entering  Explicit 
Value  Dependencies 
(F.NEXDP) 


An  assertion  source 
is  never  itself  described; 
An  assertion  target 
is  never  itself  described 


5 Entering  Conditional  (same  as  for  4) 
Value  Dependencies  (ENEXDP) 


6 Finding  Implicit 
Predecessors 
(FNDISRC) 


7 Entering  Pointing 
Relationships 
(ENPTRF.L) 

8 Cr aph  Anal ysi s 
(AT  TANA  L) 


R Cycle  Detection 
(CPFATH5 , CYCLES ) 


A field  in  a target  file 
or  interim  has  no  explicit 
predecessor  & no  deductions 
cited  in  FNDISRC  could  be  made 
An  implicit  predecessor 
found  ft  assumed  assn,  generated 
Several  possible  implicit 
predecessors  found,  hut  one 
chosen;  assumed  assn,  generated 

An  assertion  of  the  form 

POINTER. R=F  given, 

hut  P is  not  any  record 

2 or  more  source  files  are 
not  properly  related 
Field  in  source  file  unused 
Field  in  source  file 
is  the  target  of  an  assertion 
Several  assertions  have 
same  target  field  (must  he 
mutually  exclusive  conditions) 

Circular  statements  exist 


Tabl  e 4.  7a 

Error  Conditions  Detected  during  Network- 
Creation  and  Analysis 
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that  are  produced  in  each  case  and  to  an  example  of  the  error 
condition  by  means  of  an  error  number. 

Table  4.7b  summarizes,  by  number,  the  messages  themselves  which 
can  possibly  be  produced  by  the  Processor  during  the  nine  sub-phases 
in  the  matrix  creation  and  analysis  phase  and  gives  examples  of 
situations  that  give  rise  to  these  messages. 


- ...  in. I u-'  W 


1R0 

Table  4. 7b 

Summary  of  Errors  Detected  Purine.  Entire  Matrix  Analysis  Phase 
Message  1 ; 

FPROR (INCOMPLETENESS  ) : 

Need  to  know  how  to  obtain  X in  assertion  A. 

'.hen  Is sued /example: 

If  X is  a source  to  A but  never  itself  described. 

Example: 

A:  SOURCE:  X; 

TARGET:  Y; 

but  description  of  X not  given. 

Issued  by  routine:  FNEXPP  (Step  ?) 

Message  2: 

ERROR (INCOMPLETENESS  ): 

Need  to  know  hot;  to  use  X in  assertion  A. 

Mhen  Issued /Example: 

If  x is  a target  of  assertion  A but  never  itself  described. 

Example: 

A:  SOURCE:  W; 

TAP.or.T:  X; 

but  description  of  X not  given. 

Issued  by  routine:  ENEXDP  (Step  9) 

Message  3: 

ERROR (INCOMPLETENESS): 

Need  to  know  how  to  obtain  field  X. 

When  Issued /Example: 

If  field  X is  in  a target  file  or  an  interim,  but  no  assertion  exists 
that  describes  how  X is  obtained  and  nothing  can  be  deduced. 

Example: 

X IS  FIELD  (...) 

where  X is  a field  in  a target  file,  but  no  assertion  exists  which 
obtains  X. 

Issued  by  routine:  FNDISRC  (Step  5) 


k 0k 


* , 


d 


Message  4 : 


ERROR (INCONSISTENCY): 

X is  described  more  than  once  [Contradictory  descriptions  of  X] . 

Then  Issued  /Example: 

(1) If  X is  described  in  2 or  more  data  description  statements  in  the 
same  file: 

Example : 

X IS  FIELD (CHAR (2 ) ) ; 

X IS  FIELD  (NITMERIC  (9)); 

where  both  pertain  to  the  same  file;  or 

(2)  If  X is  described  as  2 or  more  files,  or  assertions,  etc.  at  the 
same  time: 

Example: 

X IS  FILE (...); 

X:  SOCRCF:  . ..;  TARGET...; 

Issued  by  routine:  FNHRRFL  (Step  15) 


Me s sane  5: 

ERROR  (INCOMPLETENESS  ): 

Files  FI,  F2,...  Are  not  related. 

Then  Is  sued /Example: 

Then  Files  FI,  F2,...  Are  source  files  but  are  not  in  any  way  related 
(by  POINTERS,  etc.). 

Issued  by  routine:  A11ANAL  (Step  a) 


Message  6. 


ERPOR (INCOMPLETENESS): 

Description  of  Croup  or  Field  X in  Y missing. 

Then  Is sued /Example: 

Y (a  file,  record,  or  group)  is  described  to  have  descendant  X,  but  X 
is  nowhere  described. 

Example: 

Y IS  RECORD  (X,V, 11); 

Y IS  FIELD  (...) 

IT  IS  FIELD  (...) 

i.e.  description  of  X is  missing. 


Issued  by  routine:  ENHRREL  (Step  14) 
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Message  7; 

ERROP (I NOONS ISTENCY): 

The  following  groups  of  items  are  circularly  described: 

• • • 

When  Is sued /Example: 


Mhen  items  are  described  circularly. 

Example : 

A:  »Y+7 ; 

B:  V=X+W ; 

0:  Y-V-HJ; 

Issued  by  routine:  PPCYCLES  (which  is  called  by  CYCLFS  enumeration 

Step  24). 


Mess ape  8; 

WARN INC  (POSSIBLE  INCOMPLETENESS ) : 

Nothing  is  obtained  from  X. 

Mh en  Is sued /Example: 

X is  a field  in  a source  file  or  is  an  interim  name,  but  it  is  never 
used  elsewhere  in  the  specification. 

Example: 

X IS  FIELD (...); 

X is  never  used  elsewhere  in  this  specification  of  the  module 
(intentionally  or  inadvertently). 

Issued  by  routine:  AN ANAL  (Step  b) 


Message  9: 

WARM INC (POSSIBLE  AMBIGUITY). 

X is  given  a value  by  assertions  Al,  A2,  ...;  they  must  be  under 

mutually  exclusive  conditions. 

When  Issued /Example : 

More  than  one  assertion  describes  how  X is  obtained;  may  be  alright  if 
under  mutually  exclusive  conditions. 


*»i>  * 
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Example: 

Al:  SOURCE:  CHOICE. Cl, Y; 
TAPCFT:  X; 


• • • 

A2:  SOUPCE:  CHOICE.C2,  U; 

TARGET:  X; 

• • • 

This  could  be  alright  if  Cl  and  C2  are  mutually  exclusive. 


Issued  by  routine:  AMANAL  (Step  c) 


Message  10: 

WAP MING (APPARENT  INCOMPLETENESS): 
Following  assertion  assumed: 

"X-Y" 


When  Issued /Ex ample: 


Mien 

(1)  X was  not  assigned  a value  by  means  of  an  explicit  assertion;  and 

(2)  it  was  possible  for  the  Processor  to  find  an  implicit  predecessor 
using  the  first  applicable  of  the  following  rules: 

(a)  X is  in  a file  which  is  both  source  and  target,  so  OLD  name  is 
assigned  to  the  NEW  name. 

Example:  NEW. X=OLD. X; 

(b)  Y has  the  same  nane  as  X,  except  that  Y appears  in  one  of  the 
source  files. 

Example:  F.XK'-.X 

where  F is  the  target  file,  and  C is  the  source  file  with  the  same- 
named  field. 

(c)  Y has  the  same  name  as  X,  and  Y is  an  interim  field. 

Example:  F. V-INTFPIM. X; 

(d)  Y has  the  same  name  as  X,  and  Y is  in  another  target  files  and 
already  has  a value  itself. 

Example:  c.X’C.X; 

where  C is  another  target  file  with  the  same-named  field,  which 
already  has  a value  assigned  to  it. 

Issued  by  routine:  FNDISRC  (Rules  1-4) 


Message  1 1: 

WARNING (APPARENT  AMBIGUITY): 
Following  assertion  is  assumed: 
"X-Y;" 


»*-'•  f Aa.: 


**  t -**.<«&* , 
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When  Issued/Example; 

Vlhen 

(1 ) X was  not  assigned  a value  by  means  of  an  explicit  assertion;  and 

(2)  the  Processor  determined  an  implicit  predecessor  using  the  first 
applicable  of  the  following  rules: 

(just  like  the  previous  set  of  messages,  except  that  here  there  is 
more  than  one  candidate  for  a predecessor,  because  of  multiple  same- 
named  fields  in  different  files,  so  the  first  such  candidate  found  is 
arbitrarily  chosen  and  printed  to  the  user). 

(a)  (see  10b). 

(b)  (see  lOd). 

Issued  by  routine:  FNPISRC  (Rules  1-4) 


Message  12: 

ERROR  (INCONSISTENCY): 

Field  X is  a source-file  field  and  cannot  be  the  target  of  assertion 

A. 


Uhen  Issued /Example: 

'./hen  X is  described  to  be  in  a file  that  is  source  to  the  module  and  X 
is  described  to  be  the  target  of  an  assertion. 

Example : 

SOURCE  FILES:  F,...; 

• • • 

F IS  FILE (...); 

X IS  FIELO  (...);  (in  file  F) 

A:  SOURCE:  Y; 

TARGET:  X; 

Issued  by:  AM ANAL  (Step  d) 


Message  1 3: 

EPPOR (INCONSISTENCY): 

POINTER. R is  used  but  R is  not  the  name  of  any  record. 

Uhen  Is  sued /Example : V'hen  a POINTER  type  assertion  of  the  form 

ro INTER. P«F  is  given,  but  p is  not  the  name  of  any  record. 

Issued  by:  ENPTP.EL  (Step  4) 


^ f-  '"mamES 
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4.3.3  Sub-phases  of  network  Creation  and  Analysis 

This  section  supplies  greater  detail  on  each  of  the  sub-phases  of 
network  creation  and  analysis,  and  the  logical  errors  that  are 
detected  by  each  phase.  Peferences  are  made  to  the  message  numbers  of 
Table  4. be. 

4. 3. 3. 1 Creating  a Dictionary  for  Row  and  Column  Numbers  of  the 
Weighted  Adjacency  Matrix 

The  "Create  Dictionary"  (CPDICT)  procedure  creates  a dictionary 
of  names,  assigning  a "node"  number  to  each.  These  names  correspond  to 


the  nodes  of  the  digraph  and  they  become  the  rows  and  columns  of  the 
Weighted  Adjacency  Matrix.  The  dictionary  data  structure  (DICT)  is  an 
array  of  strings.  An  entry  is  made  in  the  dictionary  for  each 
distinct,  fully  qualified  name  of  each  file,  record,  group,  field, 
interior,  storage  device,  or  assertion  named  in  the  user's  MODEL 
specification,  each  name  roughly  corresponding  to  a statement  in  the 
specification.  For  example,  a field  name  entry  corresponds  to  a field 


description  statement,  an  assertion  name  entry  corresponds  to  an 
assertion  statement,  etc. 

However,  there  are  exceptions  to  the  correspondence  between 


dictionary  names  and  statements  in  MODEL.  If  a file  is  described  in 
MODEL  to  be  both  a source  and  target  file,  its  component  record, 
groups,  and  fields  (described  once  in  the  MODEL  specification)  appear 
in  two  separate  entries  in  the  dictionary  (DICT)  because  they 
represent  two  distinct  entities  ("OLD"  and  "NEW").  Furthermore,  there 


T- 


are  several  types  of  "special  names"  In  a MODEL  specification  that  can 
be  the  source  or  target  of  an  assertion  (with  certain  restrictions  as 
explained  in  Chapter  3),  and  which  become  entries  in  the  dictionary. 
These  include  POINTER  names,  EXIST  names,  LEN  names,  CHOICE  names,  and 
SUBSET  names  (as  described  in  Chapter  3).  Such  special  names  are  never 
explicitly  described  in  a data  description  statement  as  fields  are, 
since  their  description  is  implicit.  They  do  however  become  nodes  in 
the  digraph  (rows  and  columns  in  the  matrix)  and  therefore  need 
dictionary  entries.  Assertions  whose  sources  or  targets  are  one  of 
these  special  names  are  treated  in  a special  way  in  code  generation  as 
shown  later. 

Algorithm  CRDICT  shows  the  details  of  the  Create  Dictionary 
Procedure.  It  goes  through  each  entry  of  the  directory  and  retrieves 
the  corresponding  statement  (Steps  1-3).  Each  name  is  fully  qualified 
with  the  filename,  "OLD"  or  "NEW"  qualifiers,  etc.  and  is  entered  in 
the  dictionary  (Steps  4-9).  It  also  creates  entries  for  the  special 
names  explained  above  (Step  10).  The  dictionary  is  alphabetized  at  the 
end  (Step  11)  and  each  name  then  has  a unique  node  number 


corresponding  to  it 


Algorithm  CRDICT:  Creating  the  Dictionary 


[Subroutines  called:  RETRIEVE] 


Step  1.  Get  next  directory  entry. 

Step  2.  If  there  are  more  directory  entries,  then  go  to  Step  3;  else 
go  to  Step  10. 

Step  3.  RETRIEVE  statements  (storage  entries)  in  which  the  name  is 
described. 

Step  4.  Branch  on  statement  type: 

RECD,  then  go  to  Step  8; 

INTR,  then  go  to  Step  6; 

FLD  or  GRP,  then  go  to  Step  7; 

FILE,  then  go  to  Step  8; 

Others,  then  go  to  Step  5. 

Step  5.  Enter  name  in  next  entry  of  dictionary  as  is;  go  to  Step  1. 

Step  6.  Qualify  Interim  Name  by  prefixing  it  with  "INTERIM."  and 
enter  in  next  entry  in  dictionary;  go  to  Step  1. 

Step  7.  Qualify  name  with  its  parent  file;  go  to  Step  8. 

Step  8.  If  corresponding  file  is  both  a source  and  a target  file,  then 
go  to  Step  9;  else  go  to  Step  5. 

Step  9.  Enter  name  in  dictionary  twice:  once  with  "NEW."  and  once 
with  "OLD."  prefix;  go  to  Step  1. 

Step  10.  Using  RETRIEVE,  find  all  CHOICE,  EXIST,  LEN,  POINTER,  & 
SUBSET  names  and  enter  each  one  in  the  dictionary  once. 

Step  11.  Alphabetize  the  dictionary  (using  standard  bubble  sort). 

Step  12.  Return. 


"X 
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4. 3. 3. 2 Creating  the  Weighted  Adlacency  Matrix  and  Entering  Precedence 
Relationships  Within  It 

The  collection  of  user-provided  names  from  the  specification 
which  now  appears  in  the  dictionary,  forms  the  rows  and  columns  of  the 
weighted  adjacency  matrix.  That  is,  the  weighted  adjacency  matrix,  M, 
is  allocated  as  an  n x n matrix  whose  rows  and  columns  correspond  to 
the  n user  names  appearing  in  the  MODEL  specification. 

Algorithm  CRADJMT  shows  the  steps  of  the  procedure  "Create 
Adjacency  Matrix"  (CRADJMT).  It  outlines  the  creation  of  the  Weighted 
Adjacency  Matrix,  including  its  allocation  (Step  1),  its 
initialization  (Step  2),  and  the  invocation  of  subroutines  that  detect 
and  enter  precedence  relationships  within  it  (Steps  2-4).  The  matrix 
is  initialized  to  all  zeros  indicating  no  relationship  between  node  i 
and  node  j (for  all  i,j)  as  a default.  The  procedure  then  proceeds  to 
call  other  routines  which  detect  and  enter  precedence  relationships  of 
various  types.  In  these  subsequent  procedures,  values  are  entered  in 
the  rows  and  columns  of  the  weighted  adjacency  matrix  by  analyzing 
relationships  in  the  MODEL  specification  submitted  by  the  user.  Many 
of  these  relationships  are  explicit  in  the  user  statements,  while 
others  are  Implicit  and  deduced  by  the  Processor.  Furthermore,  certain 
kinds  of  logical  inconsistencies  and  incompleteness  in  the  MODEL 
statements  can  be  detected  during  the  construction  and  analysis  of 
matrix  M. 


Algorithm  CRADJMT:  Creating  the  Weighted  Adjacency  Matrix  and  Entering 
Precedence  Relationships  Within  it 

(Subroutines  called:  ENDPREL, ENHRREL, ENPTREL] 

Step  1.  Allocate  the  Weighted  Adjacency  Matrix,  M as  an  nxn  matrix. 
Step  2.  Set  Mij»0  (for  all  i,j). 

Step  3.  Call  ENDPREL  (Enter  Value  Dependency  Relationships). 

Step  4.  Call  ENHRREL  (Enter  Hierarchical  Relationships). 

Step  5.  Call  ENPTREL  (Enter  Pointing  Relationships). 

Step  6. 


Return 
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4.  3.  3.  3 Entering  Hierarchical  Relationships 


Hierarchical  relationships  are  entered  in  Matrix  M between  flies, 
records,  groups,  and  fields  by  the  routine  named  ENHRREL  (ENter 
HleRarchical  RELatlonshlps) . Table  4.6  showed  that  if  item  1 contains 
Item  j,  both  of  which  are  items  in  an  input  file,  then  a "1"  is 
entered  in  the  matrix  row  of  i and  the  column  of  J,  whereas  if  item  i 
is  contained  in  item  j,  both  of  which  are  in  an  output  file,  then  a 
"2"  is  entered  in  the  row  of  i and  the  column  of  J.  This  is  due  to  the 
fact  that  the  precedence  is  opposite  in  direction  for  input  and  output 
files. 

Algorithm  ENHRREL  shows  the  procedure  to  enter  hierarchical 
relationships.  Entering  the  hierarchical  codes  is  accomplished  by 
retrieving  all  the  file  descriptions  (Steps  1-2)  and  successively 
finding  the  components  of  each.  By  means  of  a recursive  procedure 
(Step  4,  ENT_HIER_ADJ)  that  "climbs"  down  the  implicit  hierarchic  data 
structure,  each  component's  direct  descendant  statements  are  retrieved 
in  turn  and  the  hierarchical  relationship  between  a parent  and  its 
direct  descendants  is  successively  entered  in  the  matrix  M (Steps  1-7 
of  ENT-flED-ADJ  ).  Formally,  if  node  i is  the  parent  of  node  j 
(e.g.  node  i is  a record  containing  a field  node  j)  then 

Mij  - 1 if  the  current  file  is  an  input  file 

Mij  ■ 2 if  the  current  file  is  an  output  file 

Furthermore,  if  node  J is  not  a lowest  level  field  (Step  10),  then  its 
descendants  are  found,  in  turn,  and  the  procedure  is  invoked 
recursively  to  insert  the  hierarchical  relationships  with  their 
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Algorithm  ENHRREL:  Entering  Hierarchical  Relationships 

[Subroutines  called:  RETRIEVE, ENT_HIER_ADJ,ENT_MED_ADJJ 

Step  1.  RETRIEVE  all  files  or  reports. 

Step  2.  Get  next  file  or  report. 

Step  3.  If  none,  then  go  to  Step  6, else  go  to  Step  4. 

Step  4.  Call  ENT_HIER_ADJ  (Filename , Re cname) . 

(a  recursive  procedure  to  climb  down  the  data  structure  tree,  starting 
with  file  and  record). 

Step  5.  Call  ENT_MED_ADJ  (Filename, Medium  name) 

(a  routine  to  enter  relationship  between  file  and  medium). 

Step  6.  Return. 
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Enter  Hierarchical  Relationships  in  Weighted  Adjacency  Matrix  (a 
recursive  routine) 

[Subroutines  called:  RETRIEVE] 

Step  1.  Qualify  parent  and  direct  descendant  names. 

Step  2.  Let  i**dictionary  number  of  parent. 

Step  3.  Let  j“dictionary  number  of  direct  descendant. 

Step  4.  If  current  file  is  source  only,  then  go  to  Step  5; 
if  current  file  is  target  only,  then  go  to  Step  6; 
if  current  file  is  source  and  target,  then  go  to  Step  7. 

Step  5.  (source  only)  Set  Mij*l  (hierarchical  input  code); go  to  Step 

8. 

Step  6.  (target  only)  Set  Mji-2  (hierarchical  output  code);go  to  step 

8. 

Step  7.  (source  and  target) 

Set  ^dictionary  number  of  "OLD"  parent. 

Set  J*  dictionary  number  of  "OLD"  direct  descendant. 

Set  Mij-1. 

Set  i“dictionary  number  of  "NEW"  parent. 

Set  j-dictionary  number  of  "NEW"  direct  descendant. 

Set  Mji-2. 

Step  8.  RETRIEVE  direct  descendant  storage  entry. 

Step  9.  If  one  direct  descendant  storage  entry  is  found,  then  go  to 
Step  10; 

if  no  direct  descendant  storage  entry  found,  then  go  to  Step  14; 
if  more  than  1 direct  descendant  storage  entry  found,  go  to  Step  15. 

Step  10.  If  type  of  direct  descendant  is  record,  group,  or  report 
entry,  then  go  to  Step  11; 

if  type  of  direct  descendant  is  field,  then  go  to  Step  13;  else  system 
error. 

Step  11.  Get  all  of  Its  direct  descendants. 

Step  12.  For  each  one,  call  ENT_HIER_ADJ  recursively  to  enter 
hierarchical  relationships  between  it  & its  descendants  (go  to  Step 
1). 

Step  13.  (field:  no  further  direct  descendants)  Return. 

Step  14.  Print  incompleteness  message  (#6);  go  to  Step  16. 

Step  15.  Print  inconsistency  message  (#4);  Go  to  Step  16. 


Step  16, 


Return 


descendants  into  the  matrix  (Steps  11-13). 

Note  that  hierarchical  relationships  "1"  and  "2"  are  reversed  in 
direction  for  precedence  purposes  (Step  7)  because,  for  example,  a 
record  of  an  input  file  must  be  read  before  its  component  groups  and 
fields  are  available,  while  the  record  of  an  output  file  must  be 
written  after  its  component  groups  and  fields  attain  a value. 

Certain  errors  can  be  detected  during  this  process  (Steps  14-15). 
If  at  a given  node  the  indicated  descendants  do  not  exist  and 
therefore  cannot  be  retrieved  (e.g.  if  a record  X is  described  to  have 
fields  A and  B but  field  B is  never  described),  then  the  file  layout 
is  poorly-defined  due  to  Incompleteness.  Likewise,  if  at  a given  node 
more  than  one  descendant  with  the  identical  name  can  be  found  in  the 
same  file  (e.g.  field  X of  a given  file  is  described  twice  with  two 
different  sets  of  attributes),  then  the  file  is  ill-defined  due  to  an 
inconsistency.  Such  problems  are  reported  to  the  user  in  the  Network 
Analysis  Report  in  a manner  similar  to  the  following  (Message  numbers 
6 and  4,  respectively): 

ERROR (INCOMPLETENESS):  Need  a description  of  X 
or 


ERROR (INCONSISTENCY):  X is  described  more  than  once. 
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After  entering  all  the  hierarchical  relationships  in  matrix  M, 
the  storage  media  relationships  are  entered  by  the  ENter  MEDia 
ReLationships  routine  (Step  5;  ENT-MED-ADJ ) . If  a file  corresponding 
to  node  1 is  stored  on  a storage  medium  with  name  corresponding  to 
node  j,  then  Mij«6,  a code  Indicating  the  storage  relationship. 

4. 3. 3. 4 Entering  Value  Dependency  Relationships 

Value  dependency  relationships  are  entered  in  M to  indicate  that 
an  item,  j,  such  as  a field  or  assertion  depends  on  the  value  of 
another  item,  1,  and  that  therefore  item  1 is  precedent  to  item  j. 
These  relationships  are  detected  and  entered  by  the  routine  ENDPREL 
(ENter  Dependency  RELationshlps) . Some  dependency  relationships  are 
explicit  in  the  MODEL  statements,  while  others  are  implicit  and  are 
deduced  or  assumed  by  the  Processor. 

Algorithm  ENEXDP  shorn  how  value  dependency  relationships  are 
detected  and  entered  in  the  weighted  adjacency  matrix.  For  every 
explicit  assertion,  R,  appearing  in  the  MODEL  statements  (Steps  1-2), 
there  are  "source"  fields  on  which  the  assertion  R depends,  and 
"target"  fields  to  which  assertion  R is  precedent.  For  every  source 
field  which  corresponds  to  node  1,  an  "explicit  value  dependency  code" 
of  3 is  entered  in  matrix  M in  row  i and  the  column  corresponding  to 
assertion  R in  order  to  indicate  that  source  field  1 is  precedent  to 
assertion  R (Steps  5-8).  Likewise,  for  every  "target"  field  which 
corresponds  to  node  j,  the  code  of  3 is  entered  in  the  matrix  in  the 
row  corresponding  to  assertion  R and  column  j,  in  order  to  indicate 
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Algorithm  ENEXDP:  Detecting  and  Entering  Explicit  Value  Dependency 

Relationships 

[Subroutines  called:  RETRIEVE] 

Step  1.  Retrieve  all  assertions. 

Step  2.  For  each  assertion  perform  Steps  3 through  20. 

Step  3.  For  each  source  and  target  to  the  assertion,  perform 
Steps  4 through  19. 

Step  4.  If  assertion  uses  special  REPLACE  function,  then 
go  to  Step  10; 

if  assertion  uses  a conditional  function,  then  set  code«7 
(conditional  value  dependency  code); 

else  set  code* 3 (normal  explicit  value  dependency  code). 

Step  5.  (normal  case:  Steps  5 through  8): 

Set  k-dict.  no.  of  source  or  target  name. 

Step  6.  If  found  then  go  to  Step  7;  else  go  to  Step  9. 

Step  7.  Let  1 * dictionary  number  of  assertion. 

Step  8.  If  name  is  source  to  assertion,  then  set 
A(k, l)“code; 

if  name  is  target,  set  A(l,k)«code; 
go  to  Step  14. 

Step  9.  Print  incompleteness  error  (Message  #1  if  source, 

#2  if  target);  go  to  Step  14. 

Step  10.  (Replace  function  case;  Steps  10-13): 

Step  11.  Set  k*dict-no  of  EMPTY  condition. 

Step  12.  Set  l*dict-no  of  current  assertion. 

Step  13.  Set  A(l,k)*code.  (to  Insure  REPLACE  execution 
precedes  EMPTY  evaluation). 

Step  14.  If  assertion  is  specifying  a SUBSET  of  a target 
file  then  go  to  step  15;  else  go  to  step  19. 

Step  15.  (subset  case;  steps  15-18): 

Step  16.  Set  1 - dictionary  number  of  this  assertion. 

Step  17.  Set  k ■ dictionary  number  of  record  corresponding 
to  file  whose  subset  is  specified. 

Step  18.  Set  A(l,k)*code  (to  ensure  that  SUBSET  condition 
evaluated  before  the  WRITE  command). 

Step  19.  Try  next  source  or  target  name  (go  to  step  4). 

Step  20.  Try  next  assertion  (go  to  step  3). 


Step  21.  Return 
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that  assertion  R Is  precedent  to  target  field  j (Steps  5-8). 

Note  that  this  algorithm  also  handles  various  special  cases,  such 

as  assertions  that  use  conditional  functions  (Steps  4-8)  described  in 
the  next  section. 

Also  note  that  other  than  a field  or  Interim,  a source  or  target 
of  an  assertion  can  also  be  a "special  name"  not  explicitly  described 
by  the  specifier,  such  as  CHOICE  names,  EXIST  names,  LEN  names, 
etc.  explained  in  Chapter  3.  Since  such  names  correspond  to  rows  and 
columns  in  the  weighted  adjacency  matrix,  their  precedence  is  still 
entered  in  the  same  way  as  field  sources  and  targets. 

During  this  ENEXDP  process  of  entering  the  explicit  dependencies 
in  M,  certain  kinds  of  user  Incompleteness  in  the  specification  can  be 
detected  (Steps  6,9).  For  example,  if  a field  "X"  is  the  source  or 
target  of  some  assertion,  but  is  never  itself  described  as  a field  of 
any  file  or  interim  field,  then  the  assertion  is  ill-defined  because 
it  refers  to  a non-existent  field  and  the  specification  is  incomplete 
as  field  X is  never  described.  A message  is  sent  to  the  user  in  the 
Network  Analysis  Report  to  the  effect  that  there  is  an 

"Incompleteness:  Need  to  know  how  to  use  (or  obtain)  X",  and  the  user 
is  directed  to  provide  the  missing  description  or  change  the  statement 
with  the  faulty  reference,  whichever  is  appropriate  (Message  numbers  1 
and  2).  Similar  errors  are  detected  when  a target  of  an  assertion  is 
itself  undefined. 
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4. 3. 3. 5 Entering  Conditional  Dependency  Relationships 

The  above  routine,  as  shown  in  Algorithm  ENEXDP,  also  has  the 
task  of  entering  conditional  relationships  in  the  adjacency  matrix. 
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4. 3. 3. 6 Finding  Implicit  Predecessors 

If  a field  that  Is  not  in  some  Input  file  does  not  have  a value 
via  some  explicit  user's  assertion,  then  the  Processor  next  tries  to 
find  a implicit  source  for  the  field  using  a set  of  successive  rules. 
Also  during  the  following  phase,  further  analysis  is  made  of  the 
Weighted  Adjacency  Matrix,  M,  and  certain  kinds  of  inconsistency  and 
incompleteness  errors  are  detected.  Details  of  entering  such  implicit 
relationships  in  the  adjacency  matrix  and  detecting  corresponding 
errors  are  in  the  process  called  ENtering  IMplicit  DePendence 
(ENIMDP),  and  its  subroutines,  described  here. 

First,  interim  variables  are  checked  to  make  sure  that  they  have 
a predecessor.  The  HASSRC  ("HAS  SouRCe")  function  determines  whether 
an  item  has  an  explicit  predecessor.  If  an  interim  field  corresponds 
to  node  j,  then  column  J of  M is  checked  to  see  if  it  has  an  explicit 
predecessor;  i.e.  (31)(Mlj>0)«  If  so,  then  the  field  has  a source; 
otherwise,  a message  such  as  the  following  is  sent  to  indicate  its 
absence  (Message  number  3): 

ERROR (INCOMPLETENESS):  Need  an  assertion  that  describes  how 
to  obtain  interim  name  X. 


Secondly,  all  the  fields  in  target  files  are  checked  to  determine 
whether  they  already  have  an  explicit  predecessor  via  the  HASSRC 
function.  If  a given  field  in  a target  file  (a  field  corresponding  to, 
say,  node  j in  Matrix  M)  already  has  an  explicit  source  by  virtue  of  a 
user's  assertion,  then  (3i)(Mij«3).  Otherwise,  the  field  has  no 
explicit  source  and  the  Processor  tries  in  the  FNDISRC  routine  (FIND 
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Implicit  SouRCe)  to  find  a same-named  field  in  another  file  or  a same- 
named  interim  field  as  its  source  using  a set  of  successive  rules  in 
the  following  order  of  priority.  Although  there  might  be  other 
possible  and  equally  reasonable  rules  for  predecessor  assumptions, 
they  could  easily  be  incorporated  by  another  systems  programmer.  The 
idea  here  is  for  the  Processor  to  make  some  reasonable  assumption  for 
a plausible  predecessor  if  at  all  possible.  Regardless  of  the 
Processor  assumptions,  the  user  can  modify  the  result  of  the 
assumption  in  his  next  specification  iteration  by  removing,  changing, 
or  adding  assertions.  The  following  rules  are  used  by  the  FNDISRC 
Algorithm. 

Rule  1:  If  the  target  field  having  no  explicit  predecessor  is  in  a 
file  which  is  both  a source  and  target  file,  then  the  value  in  the 
corresponding  field  in  the  old  record  is  taken  as  the  value  of  the 
field  in  the  new  record  (Message  10  is  printed). 

Rule  2:  If  Rule  1 does  not  apply,  then  the  Processor  tries  to  find  a 
same-named  field  in  a source  file.  If  one  is  found,  it  is  assumed  to 
be  the  source  and  is  so  Indicated  in  a message  containing  the  assumed 
assertion  (Message  10).  If  more  than  one  same-named  field  in  a source 
file  is  found,  then  the  first  is  taken  as  a source  and  a message  is 
sent  to  Indicate  that  there  was  an  ambiguity,  and  the  assumed 
assertion  is  printed  (Message  11). 
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Rule  3:  If  no  predecessor  for  the  field  is  found  by  the  above  means, 
then  the  Processor  tries  to  find  a same-named  interim  field.  If  one  is 
found,  it  is  taken  as  the  source  and  a message  is  sent  to  indicate 
that  (Message  10).  If  more  than  one  is  found,  the  first  Is  taken  and  a 
message  is  sent  to  Indicate  that  there  was  an  ambiguity  (Messape  11). 

Rule  4:  If  the  above  efforts  are  unsuccessful,  the  Processor  tries  to 
find  a same-named  field  in  another  output  file.  If  one  is  found  it  is 
taken  as  the  source  with  a corresponding  message  given  to  the  user 
(Message  10),  and  if  more  than  one  is  found,  then  one  is  taken  with  a 
corresponding  message  to  the  user  regarding  the  ambiguity  (Message 
11). 

Rule  5:  In  the  above  cases,  the  Processor  tries  to  find  "implicit" 
sources  for  a field  if  none  is  given  explicitly.  If  all  this  still 
fails  to  find  some  field  which  can  be  construed  to  represent  the 
current  field's  source,  then  an  error  message  is  sent  to  the  user  to 
the  effect  that  the  current  field  has  no  assertion  describing  how  it 
is  obtained,  and  that  therefore  such  an  assertion  is  needed  (Message 
3). 


In  the  above  cases  where  an  assumption  is  made  regarding  an 
implicit  precedence,  the  corresponding  assertion  is  printed  to  the 
user  in  his  own  language,  namely  in  the  form  of  a MOREL  assertion.  A 
warning  is  printed  as  follows:  "In  the  absence  of  any  other 

relationship,  the  following  assertions  have  been  assumed:",  followed 
by  the  assumed  assertions.  The  warning  (Messages  10  and  11)  is 


produced  by  the  PRSRCWRN  routine  (PRint  SouRCe  WaRNlng). 

The  resulting  list  of  such  assumed  assertions  can  then  become  a 
permanent  part  of  the  documentation  by  appending  them  to  the  listing. 
The  assumed  assertion  is  written  out  in  the  user's  own  MODEL  language 
for  him  to  evaluate  whether  it  agrees  with  his  own  original  intention 
or  whether  some  of  the  statements  must  be  changed  and  the 
specification  resubmitted.  If  the  user  is  satisfied  with  the  assumed 
assertions  and  if  he  wishes  that  they  be  explicitly  incorporated  into 
the  specification's  original  assertions,  he  could  use  an  on-line 
editor  to  merge  the  assertions  produced  by  the  Processor  with  his  own. 

4. 3. 3. 7 Entering  Pointing  Relationships 

This  phase  of  the  Processor  has  the  simpler  task  of  entering 
"pointing"  relationships  in  the  Matrix  M.  Such  a relationship  exists 
when  a user  states  that  some  field  points  to  some  record  of  a file. 
This  is  stated  in  MODEL  with  an  assertion  of  the  form  "POINTER. R“F, " 
where  R is  the  name  of  some  record  and  F is  the  name  of  the  pointing 
field. 


For  example,  in  the  subset  of  the  Department  Store  Sale  problem 
presented  earlier  in  this  chapter,  there  is  a pointing  relationship 
between  POINTER. IN VR EC  and  INVREC.  A "pointing  code"  of  5 is  then 
entered  in  the  matrix  to  show  the  precedence  of  the  pointing  field  to 
the  keyed  record.  If  there  is  no  such  record  name  as  "R",  then  an 
error  message  is  sent  to  that  effect  to  the  user  (Message  13). 
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Algorithm  F.NPTREL  showB  the  procedure  to  enter  all  such  pointing 
relationships  into  the  matrix: 

Algorithm  ENPTREL:  Entering  Pointing  Relationships: 

[Subroutines  called:  RETRIEVE] 

Step  1.  Retrieve  all  POINTER  names. 

Step  2.  For  each  POINTER  name,  perform  steps  3 through  5. 

Step  3.  Set  i**dictionary  number  of  pointer  name. 

Step  4.  Set  J-dictionary  number  of  record  pointed  to.  If 
missing,  print  error  message  (#13). 

Step  5.  Set  Mij«5  (pointing  code). 

Step  6.  Return. 

4. 3. 3. 8 Graph  Analysis  of  Adjacency  Matrix 

After  entering  all  the  known  precedence  relationships  into  the 
weighted  adjacency  matrix,  the  matrix  such  as  the  one  shown  in  Figure 
4.  10  is  printed  out  for  the  user  by  the  PRADJMT  routine  (PRint 
ADJacency  MaTrix).  The  dictionary  of  names  appears  in  alphabetical 
order  (having  been  sorted  by  ALPHDIR)  for  the  user  alongside  the 
corresponding  rows  of  the  matrix. 

Although  by  this  time  many  logical  errors  in  the  MODEL  statements 
have  been  detected  during  the  construction  of  M,  such  as  the 
inconsistencies,  ambiguities,  and  incompleteness  explained  in  the 
previous  sections,  some  of  the  analysis  can  be  done  only  after  the 
construction  of  matrix  M is  complete. 
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Some  examples  of  Che  analysis  performed  ac  chls  stage  are  as 
follows : 

(a)  If  a given  row,  1,  of  matrix  M corresponds  to  a field  that 
has  no  direct  descendants,  l.e. 

^j) (Mlj-3  or  Mij-4) 

then  It  Is  an  "unused"  field.  If  the  unused  field  Is  an  output  field, 
then  of  course  there  Is  nothing  unusual.  If  the  unused  field  is  a 
field  in  a source  file,  then  a warning  is  sent  to  indicate  that  the 
field  is  not  used  in  any  assertion  (Message  5).  If  the  unused  field  is 
an  interim  field  then  the  digraph  is  incomplete  since  there  is  no 
assertion  involving  the  field,  and  an  error  message  is  sent  to  this 
effect  (Message  5). 

(b)  If  the  node,  say  j,  corresponding  to  a "keyeii"  input  record 
has  no  "pointing"  source,  (i.e.  an  ISAM  file  that  has  no  assertion 
"pointing"  to  its  records) 

^i)(Mij-5) 

then  there  is  no  assertion  telling  how  that  file  relates  to  other 
files.  The  digraph  is  thus  disconnected  and  therefore  incomplete.  In 
such  a case,  the  user  is  warned  that  the  two  or  more  source  file  are 
defined  but  that  there  is  no  relation  between  the  two  (Message  8). 

(c)  If  a field,  j,  has  more  than  one  assertion  as  its  source, 
i.e.  there  exist  k and  1 such  that  MkJ“MlJ"j,  then  a warning  message 
is  sent  to  the  user  indicating  that  the  two  assertions  possibly 
present  a contradiction.  In  such  a case,  the  two  assertions  can  only 
hold  if  they  are  under  mutually  exclusive  choices,  and  a corresponding 


message  is  sent  to  the  user  (Message  9). 

(d)  Another  check  that  needs  to  be  made  is  that  the  targets  of 
all  assertions  may  not  themselves  be  a field  in  a source  file;  i.e.  if 
Aij-3  where  i corresponds  to  an  assertion,  then  J may  not  correspond 
to  a field  in  a source  file  (Message  12). 

Note  that  if  any  errors  have  been  detected  during  the 
construction  or  during  the  post-analysis  of  the  weighted  adjacency 
matrix,  the  error  count  flags  the  Processor  not  to  proceed  to 
subsequent  phases,  but  to  let  the  user  resubmit  a corrected 


specification 
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4. 3. 3.9  Path  Matrix  Creation;  Cycle  Detection  and  Enumeration 

Another  important  type  of  analysis  performed  here  is  the 
detection  and  enumeration  of  any  cycles  that  might  exist  in  the 
digraph.  This  is  necessary  to  give  the  MODEL  user  feedback  about 
possible  errors  regarding  circular  definitions. 

In  order  to  perform  such  analysis,  the  path  matrix  (or 
reachability  matrix  ) of  the  digraph  is  generated  first.  The  path 
matrix,  P,  is  a matrix  of  ones  and  zeros  with  a "1"  in  row  i and 
column  j if  and  only  if  there  is  path  of  any  length  from  node  i to 
node  J.  Formally, 

Pij"l  if  there  exist  kl,k2,...,km  such  that 

A(i,kl)-A(kl,k2)-...-A(km,j)-l 

Pij»0  otherwise 

In  other  words,  the  path  matrix  indicates  which  nodes  can  be  reached 
from  other  nodes.  The  path  matrix  can  be  defined  as 
aVa'v.  . .VA* 

(sometimes  called  the  "transitive  closure"  of  A),  but  a more  efficient 
method  for  generating  it  from  the  Adjacency  Matrix,  A,  is  Warshall's 
algorithm  [WAR68] , implemented  in  the  CRPATHS  (CReate  PATH  matrix) 
subroutine.  Algorithm  CRPATHS  shows  this  procedure: 


n'V.  * 


206 


Algorithm  CRPATHS : Create  Path  Matrix: 

1.  Let  P"A  (for  all  i,j) 

2.  Set  j-1 

3.  Set  i“l 

4.  If  Pij»l  then  set  Pik»PikVPjk  (for  all  k«l  to  n) 

5.  Set  i-i+1 ; if  i<-n,  then  go  to  4. 

6.  Set  J-j+1 ; if  J<«n,  then  go  to  3;  else  return. 

Once  the  path  matrix  is  created,  the  presence  of  one  or  more 
cycles  is  detected  easily  by  searching  for  a "I"  on  the  diagonal; 
i.e.  (Ji)  (Pii**l  )•  If  there  are  no  cycles  in  the  graph,  the  system 
proceeds  to  the  next  phase  (precedence  determination).  Otherwise,  we 
need  to  enumerate  exactly  which  nodes  appear  in  which  cycles, 
information  which  the  path  matrix  itself  does  not  provide  (a  1 on  P's 
diagonal  only  tells  us  that  the  node  is  on  some  cycle).  It  is 
necessary  in  such  cases  to  enumerate  to  the  user  the  exact  distinct 
sets  of  statements  with  circular  definitions.  Algorithm  CYCLES  is  for 
enumerating  all  distinct  cycles  in  the  represented  digraph  (given  the 
adjacency  and  path  matrices).  It  is  adapted  from  [BER  71 1 which  in 
turn  is  based  on  Floyd  [FL067]. 


The  algorithm  has  3 Inputs:  the  number  of  nodes,  n;  the  Adjacency 
Matrix,  A;  and  the  Path  Matrix,  P.  The  algorithm  finds  all  the  cycles 
by  the  principle  that  node  i is  in  a cycle  with  node  k,  if  Aik  x Pki  - 
1;  i.e.  there  is  an  arrow  from  node  i to  node  k and  a path  from  k back 
to  i;  i.e.  there  is  a cycle  (i,k,...,l).  If,  however,  Aik  x Pki  ■ 0 
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Algorithm  CYCLES:  Cycle  Enumeration 


Step  1.  Root-1. 

Step  2.  (initiate  tree;  steps  2 to  6): 

Set  REACH J (k)  * Root  (for  k-Root  to  n) 

Step  3.  Set  USED  (k)  - 0 (for  k-Root  to  n) 

Step  4.  Set  level-1. 

Step  5.  PATH  (l)-Root 
Step  6.  Set  i-Root. 

Step  7.  (Test  if  current  path  can  be  extended  with  nodes  in  a cycle; 
Steps  7-11): 

If  REACHJ  (i)>n  then  go  to  Step  12. 

Step  8.  Set  j-  REACHJ  (i). 

Step  9.  If  A(i, j)*P(j,Root)-l  and  ~ USED  (J)  then  go  to  Step  18. 

Step  10.  Set  j-j+1. 

Step  11.  If  j<-n  then  go  to  Step  9. 


Step  12.  (Backtrack  in  tree,  resetting  REACHJ  and  USED  ; 
Steps  12  through  17): 

Set  REACHJ  (i)-  Root. 

Step  13.  Set  USED  (i)  - 0. 

Step  14.  Set  level-level-1. 

Step  15,  If  level-0  then  go  to  Step  26. 

Step  16.  Set  i - PATH  (level). 

Step  17.  Go  to  Step  7. 

Step  18.  (Extend  path;  Steps  18  through  23): 

Set  USED  (j)  - 1. 

Step  19.  Set  REACHJ  (i)  - j+1 
Step  20.  Set  level-level  - 1. 

Step  21.  Set  PATH  (level)  - j. 

Step  22.  Set  i-j. 

Step  23.  If  j '-Root  then  go  to  Step  7. 

Step  24.  (Print  Cyclic  Path): 

Print  PATH  (k),  k - 1 to  level  (message  #7). 

Step  25.  Go  to  Step  13. 

Step  26.  Set  Root-Root+1. 

Step  27.  If  Root  <-  n then  go  to  Step  2. 

Step  28.  Return. 
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for  all  k,  then  node  1 does  not  lie  on  any  cycle.  The  algorithm 
determines  the  cycles  by  growing  all  the  trees  such  that  Aik  x Pki  - 1 
and  the  nodes  of  each  path  of  the  tree  constitute  the  members  of  the 
cycle. 


Algorithm  CYCLES  is  best  understood  with  an  example.  Figure  4.12 
illustrates  a small  digraph  with  all  the  trees  constructed  by  the 
algorithm.  This  example  is  taken  from  [BER  71].  Each  path  from  the 
root  of  the  tree  to  the  same  terminal  node  represents  a cycle. 

Note  that  the  order  of  cycles  printed  by  the  algorithm  is  by 
lexicographic  order  of  the  node  numbers.  Since  the  corresponding 
dictionary  has  been  previously  alphabetized,  the  algorithm  prints  the 
distinct  cycles  in  alphabetical  order. 

However,  there  are  some  situations  which  the  system  currently 
does  not  check.  These  deal  with  special  MODEL  names  such  as  POINTER, 
EXIST,  etc.  As  mentioned  in  Chapter  3,  the  user  should  never  define 
LEN.X  or  EXIST. X in  terms  of  X since  there  is  an  implicit  precedence 
of  LEN.X  or  EXIST. X before  X.  If  the  user  did  this,  the  result  would 
be  a type  of  cycle  which  this  algorithm  is  not  designed  to  detect. 

An  example  of  an  illegal  cycle  in  a MODEL  digraph  would  be  a set 
of  circular  assertions  such  as  the  following: 

A-B+C 

bh:+o 

dk:+a 

In  this  example,  A depends  on  B,  B depends  on  D,  and  D depends  on  A, 


r 


210 

an  inconsistent  cycle.  In  such  a case  a message  would  be  sent  to  the 
user  in  the  Network  Analysis  Report  indicating  the  assertions  causing 
the  problem  (Message  7). 

The  only  cycle  ever  allowed  in  a MODEL  specification  is  a very 
structured  one  called  "replacement"  as  was  presented  in  Chapter  3. 
Processing  of  assertions  using  the  replacement  function  is  a subject 
that  will  be  covered  later. 

In  summary,  the  above  algorithm  enumerates  all  the  distinct 
cycles  in  the  specification.  If  there  are  illegal  cycles,  the 
Processor  would  not  proceed  to  further  stages  but  would  let  the  user 
re-submit  a corrected  specification.  Normally,  however,  no  cycles 
would  exist  and  the  Processor  proceeds  to  subsequent  phases  of 
analysis  and  design. 


With  the  Ueighted  Adjacency  Matrix  created  and  analyzed  for 
completeness  and  consistency,  and  with  the  existence  of  any  illegal 
cycles  determined,  the  network  analysis  phase  is  complete.  If  there 
are  no  inconsistencies,  ambiguities,  incompleteness,  or  any  other 
logical  errors  detected  during  this  phase,  the  Processor  continues 
with  the  created  data  structures  into  the  subsequent  phases  of 
precedence  determination,  flow  optimization,  flowchart  creation,  and 
code-generation.  Otherwise,  the  MODEL  user  has  been  presented  with  a 
set  of  reports  pinpointing  the  causes  and  nature  of  his  problem,  and 
suggestions  for  rectifying  them. 
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4.4  Autonatlc  Program  Design  and  Determination  of  Sequence  and  Control 

Logic 


This  phase  Involves  ordering  of  all  the  events  as  Implied  by  the 
precedence  graph  (represented  by  the  weighted  adjacency  matrix)  and 
determining  the  sequence  and  control  logic.  Program  design  proceeds 
with  analysis  of  scopes  and  iterations,  and  with  optimization  of  the 

flow.  The  result  of  this  phase  is  a flowchart-like  set  of  data 

structures  (and  a report)  embodying  the  sequence  and  control  logic. 

4.4.1  Precedence  Determination  and  Sequencing  Algorithm 

Once  construction  and  above  analysis  of  the  matrix  is  complete, 
the  next  task  is  to  analyze  the  matrices  for  the  purpose  of 
determining  the  sequences  of  events  according  to  precedence. 

The  basic  task  of  this  algorithm  is  to  take  a given  n x n 

adjacency  matrix.  A,  such  as  in  Figure  4.9  corresponding  to  the 

digraph  of  Figure  4.8,  to  rank  the  nodes  according  to  precedence,  and 
to  reorder  the  nodes  according  to  their  rank. 

It  is  known  from  graph  theory  (see  such  textbooks  as  [BER71 ) ), 

that  a given  adjacency  matrix  A,  gives  all  the  paths  of  length  1 from 

* 

i to  J;  Axgives  all  the  paths  of  length  2;  Ogives  all  the  paths  of 
length  J;  etc.  A multiplication  of  a matrix  by  itself  here  is  boolean. 
Therefore  one  way  of  determining  the  precedence  ordering  of  all  the 
nodes  is  by  successively  multiplying  the  adjacency  matrix  A by  itself. 
At  each  stage,  the  nodes  of  the  current  rank  would  be  those  with  an 


This  approach  is  inefficient  for  computer  implementation, 
however,  because  at  each  stage,  a matrix  multiplication  of  an  n x n 
matrix  , A,  by  another  n x n matrix.  A*  ,*  would  be  involved  to  get  A*. 
To  produce  the  A matrix  at  each  of  the  up  to  n stages  involves  n 
steps  (n  row-column  matches  for  each  of  the  n entries  of  the  matrix) 
with  the  non-zero  elements  being  multiplications.  Thus,  the  entire 
process  takes  on  the  order  of  n steps. 


A much  quicker  algorithm  for  determining  the  order  of  precedence 
is  given  in  Algorithm  PRECED.  The  explanations  of  each  step  are  given 
in  the  table  along  with  the  algorithm  for  readability.  This  algorithm 
is  similar  to  topological  sorting  algorithms  such  as  the  one  found  in 
[KAH62].  It  involves  analyzing  only  the  original  matrix  without  any 
multiplications  and  is  accomplished  in  n stages,  with  each  stage 
taking  2kn  steps,  where  1 <■  k <*n.  Thus  the  total  precedence 
determination  process  that  follows  takes  on  the  order  of  n steps. 

The  algorithm  works  by  first  finding  all  the  nodes  of  rank  0; 
i.e.  all  the  nodes  which  do  not  have  precedents  (Step  2).  This  is 
simply  all  the  nodes  which  have  all  zeros  in  their  column.  (In  Step  2, 
these  are  all  column  nodes  j that  are  put  in  set  D(Q);  the  "i"  in  the 
condition  are  the  row  entries  in  each  such  column  j).  These  nodes 
become  the  elements  of  rank  set  D(0),  and  the  rank  of  all  such  nodes 
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Algorithm  (PRECED):  Precedence  Determination 
the  following  symbols  are  used: 

A The  input  n x n adjacency  matrix  (row  and  column  for  each  node) 
i row  index  for  A 

j column  index  for  A 

D a vector  of  "rank  sets";  each  rank  set  (element  of  the  vector) 
consists  of  a set  of  nodes  at  that  rank;  in  the  example  in  this 
section,  D (0)«*{3, 9, 21 };  D(1 )«{15, 16};  etc. 

1 rank  counter;  index  to  D (i.e.  in  the  algorithm,  D(l)  is  the  set 
of  nodes  of  rank  1;  0 (1—1 ) is  the  set  of  nodes  of  rank  1-1,  etc.) 

n the  number  of  nodes;  also  the  number  of  rows  and  columns  of  A; 
also  the  number  of  elements  in  vectors  R and  0. 

P is  set  successively  to  each  node  in  the  previous  rank  set,  D(l- 
1);  indexes  row  of  A 

q is  set  successively  to  each  node  in  the  current  rank  set  D(l); 
indexes  column  of  A;  also  indexes  R 

R the  "rank  vector"  that  is  produced  (has  n elements);  the  index 
to  R is  a node  number;  the  value  of  each  element  of  R gives  the  rank 
of  that  node;  e.g.  R(q)  gives  the  rank  of  node  q. 

0 the  "order  vector"  produced  (has  n elements);  the  indices  to  0 
are  the  sequence  or  step  numbers  (1,2,3,...);  the  value  at  each 
element  of  0 is  the  node  number  to  be  executed  at  that  position.  In 
the  example  in  this  section,  0(1  )*9,  0(2 )»3,  etc.,  meaning  node  9 is 
fist,  node  3 is  second,  etc. 

(these  are  Illustrated  in  an  example  following  the  algorithm) 
is  set  to  0. 


Secondly,  the  nodes  of  rank  1 are  then  all  those  nodes  which  are 
direct  descendants  of  nodes  in  rank  0;  the  nodes  of  rank  2 are  then 
all  those  nodes  which  depend  on  nodes  in  rank  1 (possibly  updating  the 
previous  rank  of  some  nodes);  and  so  forth  (Steps  3-6).  At  each  stage, 
the  algorithm  has  to  check  the  rows  of  the  previous  set  of  nodes  for 
direct  descendants  (Step  5).  After  the  nodes  have  thereby  been 
partitioned  into  rank  sets,  the  order  of  execution  of  the  nodes  is 
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STEP 

1 

2. 

3 

4 

5 

6 

7 

8 
9 


ALGCR I THH 

Initialize  R to  all  zeros 

D*  r £ j j VU 

If  D0  ■ ^ Chen  go  to  9 


EXPLANATION 

Initially  Rank  vector. all.  Q 

Nodes  of  rank  0 consist 
of  oil  Chose  which 
have  no  precedents 
! . c . a 1 L 0 col umn 


1 *-  0 
1 *-1+1 

If  1 » n,  ;o.  to  9 


(Vj€  *) 

I f ± Jf  then  go  to  4 

otherwise  go  to  step  3 


Set  Order  vector  to 
Rearranged  nodes  In  Rank 
ascending  order 
(norma  1 exit) 

There  exists  at  least  1 
one  cycle  somewhere 
In  the  digraph 


Index  for  rank  set 
initially  0 


Next  rank  set  consists 
of  all  those  nodes 
which  depend  on 
something  In  the 
previous  rank 

All  nodes  In  current 
rank  set  are  ranked 
with  level  1 

I f there  are  still 

nodes  In  current  rank 
set,  go  back  to  find 
next  rank  set 

Nodes  are  now  ranked; 
simply  rearrange 
nodes  In  rank  order 

This  Is  because  the 
algorithm  has  gone 
thru  n rank  sets 
and  dependencies  stll 
exist  on  last  one 


Algorithm  PRECEDi  Precedence  Determination 


215 


simply  a re-arrangement  of  the  nodes  according  to  their  rank  (Step  8). 
The  result  of  this  algorithm  is  an  order  vec tor  0,  where  0(i)  is  the 
node  to  be  executed  at  step  i. 

The  algorithm  terminates  when  either  all  nodes  have  been  ordered 
or,  theoretically,  if  a cycle  exists  in  a network  (rank  >n).  The 
latter  is  impossible,  however,  because  any  cycles  would  have  been 
detected  in  the  earlier  cycle  detection  and  enumeration  algorithm,  and 
the  Processor  would  not  have  reached  this  point.  This  algorithm 
operates  on  a non-cyclic  digraph  and  orders  all  nodes. 

In  order  to  illustrate  the  algorithm,  it  is  applied  to  the 
Adjacency  Matrix  of  Figure  4.11,  which,  in  turn,  corresponds  to  the 
digraph  and  example  of  Figures  4.9  and  4.10.  The  rank  sets  and  rank 
vector  produced  for  this  example  are  shown  below,  while  the  nodes 
sequenced  in  precedence  order  as  a result  are  shown  in  Figure  4.13. 
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Rank  Sets 

Rank  Vec 

D(0)-{3,9,21> 

(1)  7 

(2)  11 

D ( 1 )“{1 5, 16) 

(3)  0 

(4)  10 

D(2)“{22, 23, 24 

(5)  8 

(6)  7 

D(3 )“{ 1 9, 20, 26  > 

(7)  7 

(8)  9 

D(4)-{14> 

(9)  0 

(10)  6 

D(5 )»{ I 3> 

(11)  6 
(12)  6 

D(6)-{10, 11, 12} 

(13)  5 

(14)  4 

D(7)-{1,6,7,27> 

(15)  1 

(16)  1 

D(8)-{5, 18> 

(17)  10 

(18)  8 

D(9)-{8, 25> 

(19)  3 

(20)  3 

D(10)»{4,17> 

(21)  0 
(22)  2 

D(ll)«<2> 

(23)  2 

(24)  2 

(25)  9 

(26)  3 

(27)  7 
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SEQUENCE  OF  PROCESSING 
ORDER 

VECT.  ORDER  NAME  RANK 

INDEX  VECTOR 


1 

3 

MINSALE 

0 

2 

9 

OLD. IN VEN 

0 

3 

21 

SALETRAN 

0 

4 

15 

SALEDECK 

1 

5 

16 

SALEREC 

1 

6 

22 

SALETRAN. CUST# 

2 

7 

23 

SALETRAN. QUANTITY 

2 

8 

24 

SALETRAN. STOCK# 

2 

9 

19 

SALESLIP.CUST# 

3 

10 

20 

SALESLIP. STOCK# 

3 

11 

26 

TRINV 

3 

12 

14 

PO INTER. OLD. IN VR EC 

4 

13 

13 

OLD. IN VR EC 

5 

14 

10 

OLD. INVEN.  QOH 

6 

15 

11 

OLD. INVEN. SALPRICE 

6 

16 

12 

OLD. INVEN. STOCK# 

6 

17 

1 

CALCCHRG 

7 

18 

6 

NEW. INVEN. SALPRICE 

7 

19 

7 

NEW. INVEN. STOCK# 

7 

20 

27 

UPDQUAN 

7 

21 

5 

NEW. INVEN. QOH 

8 

22 

18 

SALESLIP. CHARGE 

8 

23 

8 

NEW.INVREC 

9 

24 

25 

S LI  PR  EC 

9 

25 

4 

NEW. INVEN 

10 

26 

17 

SALESLIP 

10 

27 

2 

INVDISK 

11 
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At  this  stage,  the  Processor  does  not  show  the  detailed  tasks  taking 
place  at  each  node  or  the  control  logic.  Those  details  are  generated 
later  In  the  "Flowchart  Table  Generation"  phase  (Section  A. 4. 3).  Some 
of  these  nodes  will  correspond  to  code  to  be  generated.  Notice  that 
the  order  that  could  be  generated  here  is  not  unique  since  nodes  of 
the  same  rank  set  could  come  in  any  order.  Also,  compare  the  generated 
order  of  Figure  4.13  with  the  digraph  of  Figure  4.10  to  observe  the 
sequence  of  events. 

The  generated  sequence  of  nodes,  or  order  vector  is  the  backbone 
of  the  sequence  and  control  logic  design.  It  is  subsequently  used  in 
the  "flowchart"  and  code  generation  phases  which  generate  code 
corresponding  to  each  node,  a subject  to  be  dealt  with  later. 

Another  by-product  of  this  algorithm  is  the  identif ication  of 
events  that  can  occur  in  parallel;  i.e.  those  of  the  same  rank  set. 
For  example,  nodes  23  and  24  (NEW.INVREC  and  SLIPREC)  could  be 
executed  in  parallel  since  they  are  in  the  same  rank  set  (rank  9).  In 
this  example,  they  are  both  records  so  the  WRITE  statements  to  be 
generated  later  could  theoretically  be  executed  in  parallel.  This 
could  become  Important  in  the  future  for  system-generated  code  for  a 
parallel  processor,  and  appears  later  for  the  user  in  the  Flowchart 
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4.4.2  Scope  and  Iteration  Analysis 

This  routine  (FLOWOPT)  has  the  tasks  of  (1)  determining  the 
scopes  of  the  iterations  described  in  the  specification  by  use  of  the 
FOREACH  option  for  repeating  groups  or  fields;  (2)  ensuring  that  the 
events  taking  place  within  each  iteration  are  only  those  that  are 
necessary;  and  (3)  re-ordering  those  events  not  involved  in  the  loop. 
Algorithm  FLOWOPT  shows  the  steps  of  this  process.  It  involves 
analyzing  the  order  vector  produced  in  the  previous  section.  Steps  2 
through  6 are  concerned  with  finding  the  beginning  of  a loop.  The 
first  assertion  using  a FOREACH  name  (as  either  source  or  target)  that 
has  not  yet  been  entered  in  the  list-of-loops  including  this  node 
begins  a loop.  Therefore  each  assertion  heading  is  examined  for  every 
source  or  target  name  to  check  if  it  uses  a FOREACH  that  has  not  been 
accounted  for  yet  at  the  current  node  (Steps  3-6).  The  last  node  in 
the  loop  (El)  is  found  by  looking  for  the  furthest  node  in  the  order 
vector  that  also  uses  the  current  FOREACH  name  (Step  7).  The  position 
of  the  last  node  of  the  loop  is  also  saved  in  Step  8 because  it  might 
change  as  some  nodes  are  moved  beyond  the  end  of  the  loop  later 
(i.e.  El  may  change).  Steps  9 through  13  deal  with  analyzing  the  nodes 
in  the  scope  and  determine  which  nodes  in  between  are  to  be  included 
in  the  scope.  Each  node,  beginning  with  the  start  node  (Step  9)  and  up 
to  the  ending  node  (Step  16),  is  analyzed  as  to  whether  or  not  it 
belongs  in  the  loop.  At  this  point,  nodes  that  do  not  belong  in  the 
scope  may  well  be  caught  in  the  middle  of  this  range  simply  because  of 
their  ranking.  The  nodes  to  be  included  in  the  scope  of  the  iteration 
are  only  those  nodes  which  are  descendants  of  nodes  above  them  in  the 


Algorithm  FLOWOPT:  Flowchart  Scope  Analysis  and  Optimization 
The  following  symbols  are  used: 

0 the  input  order  vector  as  defined  in  Algorithm  PRECED 

1 index  to  0;  0(i)  is  the  node  number  at  position  i 

n the  number  of  elements  of  vector  0,  which  is  also  the  number  of 

rows  and  columns  of  P 

P the  path  matrix  as  defined  in  Section  4.3.3. 9 (the  row  and 
column  indices  are  node  numbers) 

51  position  of  the  starting  node  of  current  loop 

El  position  of  the  ending  node  of  the  current  loop 

1 index  to  0 to  find  end  of  loop 

B position  of  the  last  node  that  has  been  moved  out  of  and  beyond 

end  of  loop 

k is  set  successively  to  nodes  in  the  order  vector  0 between  SI 
and  El 

52  starting  position  of  each  other  loop  in  succession  used  in 
checking  consistency 

E2  ending  position  of  each  other  loop  in  succession  used  in 
checking  consistency 

j index  to  0 (between  SI  and  k) 

CUP.RENT-FOREACH 

name  of  current  FOREACH  variable 
LIST-0F-UR1TES-T0-BE-M0VED-D0WN 

list  of  names  of  records  and  files  to  be  moved  beyond  end  of  loop 
NODES -MO VED-TO-TOP-FLAG 

flag  set  to  0 before  any  nodes  are  moved  in  front  of  start  of  current 
loop;  set  to  1 after  a node  is  moved  to  the  top 

LIST-OF-LOOPS 

list  of  data  about  each  loop  as  follows: 


START -0F-L00P  END -OF -LOOP  FOREACH-NAME 
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Algorithm  FLOWOPT:  Flowchart  Scope  Analysis  and  Optimization 
Step  1.  Set  i“l  (start  with  first  node) 

(Finding  beginning  of  next  loop,  Steps  2-6): 

Step  2.  If  node  0(i)  corresponds  to  an  assertion  then  go  to  Step  3; 
else  go  to  Step  20. 

Step  3.  If  assertion  uses  any  more  fields  with  a FOREACH  name  (as 
either  source  or  target)  then  go  to  Step  4;  else  go  to  Step  20. 

Step  4.  Set  CURRENT-FOREACH  -name  of  this  FOREACH  variable 

Step  5.  If  this  loop  has  already  been  considered  (i.e.  there  is  a 
FOREACH  name  in  the  LIST-OF-LOOPS  - CURRENT-FOREACH  & START-OF-LOOP 
<-i<-  END-OF-LOOP  in  the  LIST-OF-LOOPS  entry) 
then  go  to  Step  3. 

Step  6.  Set  Sl«i  (start  of  current  loop). 

Step  7.  (Finding  end  of  loop): 

Set  El-largest  1 such  that  node  0(1)  is  an  assertion  with  CURRENT- 
FOREACH 

Step  8.  Set  B»E 1 (initial  position  of  last  node  that  has  been  moved 
out  of  and  beyond  end  of  loop) 

(Analyzing  scope,  Steps  9-16): 

Step  9.  Set  k**Sl+l  (begin  with  next  node  in  loop  after  SI) 

Step  10.  Set  M0VED-N0DES-T0-T0P-FLAG  -0 
Clear  LIST-OF-WRITES-TO-BE-MOVEO-DOUN. 

(initially  no  nodes  have  been  moved  before  or  after  the  loop) 

Step  11.  If  node  0(k)  is  a descendant  of  any  node  between  SI  and  k 
(i.e.  there  is  a J,  Sl<-j<k  such  that  P [0 ( j ) ,0 (k) ) -1 ) 

OR  if  node  0(k)  is  an  assertion  using  CURRENT-FOREACH  (a:,  either 
source  or  target) 

then  node  0(k)  belongs  in  loop,  go  to  Step  14. 

Step  12.  (Node  0(k)  does  not  belong  in  loop  and  needs  to  be  moved  in 
front  of  loop). 

Move  node  0(k)  to  position  before  SI  by  switching. 

Set  Sl-Sl+1  (so  that  it  still  points  to  beginning  of  loop). 


f ‘'•if. . 


" I 
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Step  13.  Set  MOVED-NODES-TO-TOP-FLAG-1 

Step  14.  If  node  O(k)  is  a repeating  group  or  field  in  a target  record 
that  is  using  CURRENT-FOREACH  , then  retrieve  its  parent  record  & file 
names  & save  in  LIST-OF-WRITES-TO-BE-MOVED-DOWN. 

Step  15.  If  node  0(k)  is  in  LIST-OF-WRITES-TO-BE-MOVED-DOWN  then  move 
node  0(k)  after  the  end  of  the  loop  (by  switching  node  0(k)  up  to 
position  B,  and  setting  E1*E1-1  so  that  it  still  points  to  end  of  loop 
not  including  the  moved  nodes). 

Step  16.  (look  at  next  node  in  scope): 

Set  k-k+1 

If  k>El  then  go  to  Step  17;  else  go  to  Step  11. 

Step  17.  Add  entry  to  LIST-OF-LOOPS : 

Set  START-0F-L00P-S1 

Set  END-0F-L00P-E1 

Set  FOREACH-NAME<URRENT-FOREACH 

Step  18.  Set  S2«  START-OF-LOOP  of  each  other  loop,  in  succession,  in 
LIST-OF-LOOPS 

Set  E2"  END-OF-LOOP  of  each  other  loop,  in  succession,  in  LIST-OF- 
LOOPS 

Check  consistency  of  scope  of  current  loop  with  respect  to  others; 
check  that  one  of  the  following  must  hold;  if  not,  then  error. 

S1<-S2<-E2<-E1  or 
S2<-S1<-EK-E2  or 
S1<-E1<S2<-E2  or 
S2<-E2<S1<-E1. 

Step  19.  If  any  nodes  were  moved  before  position  SI  (i.e.  MOVED-NODES- 
T0-T0P-FLAC*1 ) then  go  to  Step  2 (the  scan  for  next  loop  will  start  at 
i to  check  for  possible  other  loops  in  the  nodes  moved  to  the  top); 
otherwise  go  to  step  3 (to  check  if  node  0(i)  begins  any  other  new 
loop) . 

Step  20.  (Get  next  node  in  0): 

Set  i-i+1 

If  l>n  then  go  to  Step  21;  else  go  to  Step  2. 


Step  21.  Return 
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loop  or  ocher  nodes  which  also  use  Che  currenc  FOP  EACH  (Seep  14).  For 
Che  dual  purpose  of  unCangling  Che  scopes  and  for  opclmlzadon,  only 
such  nodes  chac  belong  in  Che  scope  of  Che  iCeraCion  are  lefc  in  Che 
loop  by  moving  ouC  Chose  ChaC  do  noC  belong  (Seep  12). 

When  nodes  are  moved  Co  Che  polnc  imnediaCely  preceding  Che  scare 
node,  chey  keep  Cheir  reladve  posicion  Co  each  ocher.  They  are  said 
co  be  invarianc  Co  Che  iCeraCion  since  chey  do  noC  depend  on  Che 
repecicion.*  In  such  cases  of  nodes  moved  Co  Che  Cop,  a flag  is  sec 
(Seep  13)  because  when  Chis  loop  is  finished  being  analyzed  laCer 
(Seep  19),  che  scan  for  ocher  loops  will  be  resumed  scarcing  wich 
Chese  moved  nodes.  This  was  also  one  of  Che  reasons  for  Seep  S Co 
ensure  ChaC  each  discincC  loop  is  analyzed  once. 

Ic  should  be  noCed  ChaC  when  records  are  caughC  in  Che  scope  of 
Che  loop,  somecimes  Che  associaCed  inpuC/ouCpuC  command  remains  in  Che 
loop,  wherease  ac  oCher  Cimes  ic  should  noC.  For  example,  a record 
having  a poinCer  Co  ic  by  means  of  a POINTER  Cype  assercion  using  Che 
currenc  FOREACH  depends  impliciCly  on  Che  same  FOREACH  icself;  ic 
Cherefore  should  be  in  che  loop.  This  is  accomplished  by  che  condicion 
in  Seep  11.  However,  CargeC  records  conCalning  a repealing  group  or 
field  using  Che  currenc  FOREACH  name  could  conceivably  be  caughC  in 
Che  middle  of  Che  loop  due  Co  ranking,  buc  Chey  should  be  moved  beyond 
Che  end  of  che  loop  because  che  iCeraCion  is  "filling  up"  che 


* The  PL/1  Opdmizing  Compiler  also  removes  invarianc  operacions  ouC 
of  an  iCeraCion,  buc  ics  opcimizacion  is  noc  as  general  or  as  complex, 
because  Che  scopes  of  Che  lCeraClons  are  pre-designaCed  expliciCly  for 
ic  by  Che  programmer's  concrol  code  (DO  and  maCching  END  sCacemenCs). 
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repeating  group  or  field,  and  the  record  need  not  be  written  until  it 
is  complete.  Therefore  such  records  are  moved  beyond  the  end  of  the 
loop  (Steps  14-15). 

The  algorithm  goes  on  to  examine  each  node  between  the  start  node 
and  the  end  node  successively  (Step  16)  to  check  whether  or  not  it 
belongs  in  the  loop,  until  the  ending  point,  El,  is  reached. 

When  the  scope  and  constituents  of  the  loop  are  finished  being 
determined,  the  information  is  put  into  the  LIST-OF-LOOPS  (Step  17). 

Another  step  in  this  procedure  is  to  ensure  that  the  different 
iteration  scopes  implied  in  the  specification,  if  there  is  more  than 
one,  have  consistent  scopes  (Step  18).  Each  distinct  pair  of 
iterations  must  be  either  disjoint  or  nested.  That  is,  if  Il-(sl,el) 
and  I2-(s2,e2)  represent  the  iteration  scopes  of  iterations  II  and  12 
(with  s-starting  node  and  e-ending  node),  then  one  of  the  following 
must  hold  true  for  the  scopes  to  be  meaningful: 

(1)  (a)  s 1 <-s2<-e2<-el  (i.e.  12  nested  in  II); 

(b)  s2<-sl<-el<-e2  (i.e.  II  nested  in  12); 

(2)  (a)  sl<-el<s2<-e2  (i.e.  II  disjoint  and  precedes 

12); 

(b)  s2<-e2<sl<-el  (i.e.  12  disjoint  and  precedes  II). 


it  t Xr. 


If  the  scopes  are  otherwise  "tangled",  a message  is  sent 

ERROR (INCONSISTENCY):  FOREACH  x AND  FOREACH  y HAVE 

INCONSISTENT  SCOPES 


The  final  output  of  this  procedure  is 

(1)  an  updated  order  vector; 

(2)  an  updated  rank  vector; 

(3)  a list  of  iteration  scopes  with  the  following  information 
for  each  scope  (sorted  on  the  index  to  the  order  vector): 

(a)  starting  node; 

(b)  ending  node; 

(c)  the  governing  iteration  variable  (FOREACH  name). 


These  lists  (DOTAB  and  ENDTAB)  are  used  later  by  the  "flowchart 
generation  procedure"  to  generate  the  equivalent  of  PL/1  iterative 
statements  ( "DO-loops") . 


Many 

kinds  of 

optimization  can  be 

performed  both 

locally 

and 

globally. 

However 

, these  are  left 

to 

the  compiler 

which 

will 

eventually 

receive 

the  generated  program 

because  they 

are 

known 

technology. 
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4.4.3  Generation  of  Flowchart  Table 

This  sub-phase  is  concerned  with  the  generation  of  a conceptual 
"flowchart"  of  the  desired  object  module,  independent  of  the  object 
programming  language,  in  the  form  of  a table,  from  which  generation  of 
two  products  would  subsequently  follow  easily: 

(1)  the  object  PL/1  program;  and 

(2)  a flowchart-like  report. 

The  previous  phase,  which  analyzes  the  network  relationships  (Section 
4.3),  and  the  first  two  sub-sections  of  this  phase,  which  determine 
precedence  (Section  4.4.1)  and  iterations  (Section  4.4.2),  resulted  in 
a set  of  data  structures:  the  adjacency  matrix,  path  matrix,  order 
vector,  and  iteration  list.  The  Processor  now  continues  L < build  the 
"flowchart"  from  these  data  structures.  Recall  that  this  entire  phase 
(Section  4.4)  would  not  be  reached  had  there  been  user  errors  detected 
during  network  analysis  (Section  4.3). 

In  a sense,  the  order  vector  that  was  generated  during  the 
precedence  determination  phase  already  presents  a skeleton  flowchart 
of  the  object  program,  because  it  defines  the  names  of  each  node  in 
the  order  that  the  corresponding  event  is  to  be  executed.  For  example, 
if  a node  of  the  order  vector  is  the  name  of  a record  which  is  in  a 
source  file,  it  would  correspond  to  a READ  statement  (among  other  code 
associated  with  input/output)  to  be  executed  at  that  point.  In  order 
to  complete  the  list  of  names  in  the  order  vector  into  a flowchart  and 
then  a program  however,  we  need  to  get  more  information  about  each 
node  to  the  extent  that  the  PL/1  code  necessary  to  effect  the  desired 
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operation  could  then  be  generated.  Returning  to  the  same  example,  if  a 
node  in  the  order  vector  represents  the  name  of  an  input  record,  we 
need  such  additional  information  as  the  length  of  the  record,  whether 
it  has  fixed  or  variable  length,  the  name  of  the  associated  file,  the 
file  organization,  etc.  before  we  could  generate  the  corresponding 
PL/1  READ  statement.  All  such  needed  information  about  a given  node, 
however,  is  very  readily  available  by  use  of  the  retrieval  sub-system 
that  was  described  in  Section  4.2.3,  capitalizing  on  the  internal 
associative  organization  of  the  user  specification.  For  example,  in 
order  to  retrieve  the  storage  entry  on  the  file  in  which  the  record 
name  is  contained,  we  issue  the  following: 

CALL  RETRIEVE  (RECNAME  || ' &$FILE ',...) ; 

Thus,  creating  the  flowchart  of  the  desired  program  module 
involves  linearly  traversing  the  order  vector,  and  for  each  node, 
determining  the  type  of  operation  that  corresponds  and  retrieving  all 
the  relevant  information  needed  in  order  to  generate  the  necessary 
corresponding  PL/1  statement  or  statements  subsequently. 

As  Figure  4.14  indicates,  we  have  a two  step  process: 

(1)  generating  a table  of  events  or  flowchart;  and 

(2)  generating  the  corresponding  PL/1  code. 


* 
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The  fact  that  PL/1  code  Is  not  generated  directly  and  that  the 
Intermediate  flowchart  table  is  created  has  many  justifications.  It 
makes  the  program  generation  process  more  modular.  The  intermediate 
language-independent  table,  which  contains  the  type  of  operation  and 
associated  information  at  each  step,  can  be  examined  without 
involvement  in  the  intricacies  and  syntax  of  the  object  PL/1  language. 
In  fact,  as  just  shown  in  the  figure,  a pictorial  version  of  the 
flowchart,  to  be  described  later,  could  be  generated  from  the  table 
and  be  useful  to  the  systems  programmer.  Moreover,  the  entries  in  the 
flowchart  table  are  language  independent  to  the  extent  that  code  could 
be  generated  for  another  language  such  as  COBOL,  changing  only  the 
code  generation  portion  that  follows  flowchart  generation. 

4.4.3. 1 Control  Module  for  Generating  Flowchart  Table 

This  module  of  the  Processor  traverses  the  nodes  of  the  order 
vector,  one  at  a time,  determines  the  type  of  node,  and  calls  the 
appropriate  subroutine  which  creates  an  entry  of  that  type  in  the 
flowchart  table.  Each  entry  in  the  flowchart  table  to  be  generated  has 
the  following  general  form: 


■+ 


Z_U) 


iNode//  iNode  type|Name  |Operation  & auxiliary  information! 

I I I I I 

H H k +- + 

where  the  node//  is  the  index  to  the  dictionary  entry  (the  dictionary 
of  names  described  in  Section  4.3.3. 1)  with  the  node's  name  (the 
current  node  being  traversed),  for  which  code  is  being  generated;  the 
node  type  is  an  abbreviation  indicating  the  kind  of  name  to  which  the 
node  corresponds  (for  example,  record,  field,  assertion);  and  the 
operation  and  auxiliary  information  contain  all  that  is  needed  to 
generate  code  for  that  node  (for  example,  READ  and  its  parameters). 

Algorithm  GENFLT  shows  the  Generate  Flowchart  procedure,  the 
subroutines,  which  are  called  on  the  basis  of  the  node  type  (Step  5), 
will  have  the  task  of  filling  in  this  information  for  the  particular 
kind  of  operation.  The  operation  and  auxiliary  information  for  each 
node  type  is  des'-ribed  in  each  subsequent  section.  Figure  4.  15  shows 
the  components  of  generating  the  flowchart  table  presented  as  routines 
in  the  sections  to  follow.  These  include  identifying  input/output 
commands  (IDIOCIl),  identifying  assertions  information  (IDASSN), 
identifying  field  associations  (II)FLDAS),  and  generating  a table  of 
declarations  (GDCLT).  The  control  routine  also  calls  routines  (CHECKDO 
and  CHECEND  in  Steps  2 and  6)  to  check  the  iteration  table  upon  each 
step  through  the  order  vector  for  possible  generation  of  Iterative 
control  structures  (for  "DO-loop  and  END  statement  in  PL/1). 
Furthermore,  it  '•ails  a routine  to  check  for  generation  of  statement 
labels  when  necessary  (Step  4,  CHECLAB).  At  the  end  of  looping  through 
the  order  vector  and  invoking  the  corresponding  flowchart  generation 
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Algorithm  GENFLT:  Generate  Flowchart  Table 

[Subroutines  called:  CHECKDO,  CHECOND,  CHECLAB,  CHECEND,  IDASSN, 

IDIOCD,  IDFLDAS,  I DMODNM ] 

Step  1.  Set  i*l. 

Step  2.  Call  CHECKDO  (check  for  iterations). 

Step  3.  Call  CHECOND  (check  for  conditionals). 

Step  4.  Call  CHECLAB  (check  for  labels). 

Step  5.  Branch  on  Node  Type  of  0(i)  (the  "Order  Vector"  as  described 
in  Section  4. 4.  1): 

If  Node  Type*  ASSN  then  call  IDASSN  (Identifying  assertions 

information). 

If  Node  Type-  RECD  or  RPTN  then  Call  IDIOCD  (identifying  i/o 

commands ) . 

If  Node  Type*  FLD  or  INTR  then  Call  IDFLDAS  (identifying  field 
associations) . 

If  Node  Type*  MODL  then  Call  IDMODNM  (identifying  module  name). 

If  other  type,  then  create  dummy  flowchart  table  entry. 

Step  6.  Call  CHECEND  (Check  for  end  of  iterations). 

Step  7.  Set  1-1+1. 

Step  8.  If  l<-n  then  go  to  Step  2. 

Step  9.  Call  IDRSET  (reset  housekeeping  variables). 

Call  IDGOTO  (generate  branch  to  next  read). 

Call  IDF1N  and  IDEMD  (end-of-program  wrapup  tasks). 

Step  10.  Return. 


w v ..  y.  • 
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routine,  subroutines  are  called  (Step  9)  to  identify  "housekeeping" 
variables  that  need  to  be  reset  (1DRSET);  to  identify  a branch  to  read 
the  next  record  (GENGOTO);  to  identify  the  end  of  program  wrapup  tasks 
(IDFIN  and  IDEND).  All  these  subroutines  are  described  in  the 
subsections  that  follow. 

A. 4. 3. 2 Identifying  the  Module  Name 

The  routine  to  "Identify  Module  Name"  (IDMODNM)  is  a trivial  one 

whose  task  is  to  retrieve  the  module  name  and  create  a flowchart  entry 

for  it.  This  routine  is  invoked  from  the  "Generate  Flowchart  Table" 

routine  when  it  detects  the  name  of  a module,  which  should  be  the 

first  entry  of  the  order  vector.  This  routine  simply  creates  an  entry 

in  the  flowchart  table  in  the  following  form: 

+— — — — — +—  ——————— — — — —————— — — — + 

I I I I 

| NODE#  INODE  TYPE  | MODULE  NAME  | 

III  I 

where  the  NODE#  is  the  number  of  the  node  as  given  by  the  order 
vector;  NODETYPE  is  set  to  'MODL'  to  indicate  that  the  node  is  for  a 

module  statement;  and  the  MODULE  NAME  is  as  given.  This  flowchart 

table  entry  will  be  used  later  by  the  corresponding  code-generation 
routine  to  generate  the  PL/1  procedure  declaration. 


- varfjp.*-*  ’ 


' •*  *9^  . 


234 


An  example  of  such  an  entry  from  the  module  statement  of  the 
MINSALE  problem  presented  earlier  In  this  chapter  is  the  following: 

ill  I 

13  IMODL  | MINSALE  | 

III  I 

-4— ———————4——————————————+ 

4.  4.  3.  3 Identifying  Ir.put/Output  Commands 


The  routine  "Identify  Input/Output  Commands"  (IDIOCD)  has  the 
task  of  collecting  all  the  information  necessary  for  the  writing  of  an 
input/output  statement  in  the  final  PL/1  program.  This  routine  is 
invoked  from  the  Generate  Flowchart  Table  (GENFLT)  procedure  described 
in  the  previous  section,  upon  finding  a node  with  a record  name.  It 
has,  as  input,  the  dictionary  entry  of  the  record  name  for  which  code 
is  being  generated.  The  generated  input/output  operations  and 
information  that  will  be  needed  later  to  generate  the  PL/1  code  is  put 
into  an  entry  of  the  flowchart  table  ( FLOWTAB_R EC ) which  has  the 
following  format: 
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This  information  has  the  meaning  explained  below,  and  is  used 
during  the  code  generation  phase  to  produce  i/o  operations.  The 
components  of  this  flowchart  table  entry  are  either  given  to  this 
procedure  or  the  information  is  readily  available  from  the  stored 
statements  via  the  RETRIEVE  system. 

Algorithm  IDIOCD  describes  the  "Identifying  I/O  Commands" 
procedure,  and  how  it  creates  this  flowchart  table  entry. 

NODE)?  is  the  entry  number  within  the  dictionary  containing  the 
record  name,  for  which  code  is  being  generated.  This  is  passed  from 
the  calling  program  (Step  1). 

NODE  TYPE  is  set  to  'RECD'  to  identify  that  this  entry  is  an 
input/output  operation  for  a record  (Step  2). 

RECNM  is  the  name  of  the  record  for  which  the  input/output 
operation  is  being  generated.  It  comes  directly  from  the  dictionary 
entry  given  to  this  procedure  (Step  3). 

IOMODE  is  set  to  'RD',  'WR',  or  'RW'  by  this  procedure  in  order 
to  indicate  whether  the  generated  command  is  to  be  a 'READ',  'WRITE', 
or  'REWRITE',  respectively  (Step  9);  this  is  determined  according  to 
whether  the  file  is  source  or  target  and  whether  the  file  organization 
is  sequential  or  indexed  according  to  the  chart  below.  The  information 


is  available  by  retrieval 
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Algorithm  IDIOCD:  Identify  Input/Output  Code 
[Subroutines  called:  RETRIEVE] 

Step  1.  Set  NODE#  in  flowchart  table  entry  to  current  node#. 

Step  2.  Set  NODETYPE  to  RECD  . 

Step  3.  Set  RECNM  to  name  of  record  according  to  DICT  (node#). 

Step  4.  RETRIEVE  storage  entry  for  record  name. 

Step  5.  RETRIEVE  corresponding  file  name,  key  name,  and  storage 
device. 

Step  6.  If  file  is  keyed,  set  KEYED  flag  to  1;  else  set  to  0. 

Step  7.  RETRIEVE  file  organization. 

Step  8.  Add  a suffix  to  the  file  name  (FLNAME)  according  to  the  "File 
Name  Formation"  chart  shown  and  explained  in  the  text  below. 

Step  9.  Determine  IOMODE  as  READ,  WRITE,  or  REWRITE  according  to 
record  use  and  file  organization  (see  next  chart  in  this  section). 

Step  10.  If  record  is  target  and  had  a subset  specif ication,  then 
generate  a conditional  flowchart  table  entry  to  circumvent  the  WRITE 
(generates  "IF  'SUBSET. f ilename") . 

Step  11.  (see  Algorithm  IDPACK  for  details  of  this  procedure).  If 
record  has  any  variability  in  lengths  or  repetitions,  then  create 
"packing"  information  in  flowchart  entry. 

Step  12.  Write  flowchart  table  entry. 

Step  13.  Return. 


* t:  • ■* 
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"Input/Output  Mode  Determination"  Chart 
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FLNAME  is  the  name  of  the  file  from  which  the  input/output 
operation  is  to  be  performed.  It  is  directly  retrievable  from  stored 
statements.  In  order  to  make  the  file  name  unique,  however,  a suffix 
indicating  its  use  (source,  target,  or  both)  is  added  to  it  (Step  8), 
as  shown  in  the  chart  below.  The  name  formed  here  is  the  external  file 
name  that  will  be  used  to  declare  the  file  in  PL/1  and  will  be 
referenced  by  all  the  generated  input/output  statements  for  that  file. 
The  main  reason  that  the  suffix  is  added  is  to  distinguish  it  from  the 
file  name  as  given  by  the  user  which  is  reserved  for  the  name  of  the 
highest  level  tree  of  an  internal  hierarchic  buffer  in  the  generated 
program  (to  be  described  later  in  Section  A.  A. 3.  11).  The  reason  the 
original  file  name,  as  given  by  the  user,  is  used  for  the  hierarchical 
structure  is  that  it  enables  the  user  to  qualify  field  names  by 
referring  to  the  files  in  which  they  are  contained.  For  example,  a 
user  may  refer  to  a STOCK#  field  in  the  INVEN  file  as  INVEN. STOCK#, 
and  therefore  INVEN  should  be  the  name  of  the  highest  level  in  the 
internal  tree-structured  buffer. 


"File  Name  Formation"  Chart 
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ORG  is  set  to  'S'  if  the  file  is  sequential  or  to  'I'  if  the  file 
is  indexed.  This  information  is  available  from  the  storage  description 
statements  which  are  stored  and  retrievable  by  a call  to  the  retrieve 
system  (Step  7). 

KF.YED  is  a flag  set  to  1 if  the  file  is  "pointed  to"  or  "KEYED  ; 
i.e.  if  the  key  name  in  the  stored  statement  is  non-blank;  it  is  set 
to  0 otherwise  (Step  6). 

KEYNM  is  the  name  of  the  field  within  the  record  serving  as  the 
key  field.  It  is  retrievable  from  the  file  description  statement  (Step 


239 


PACK1NF  is  information  needed  to  generate  code  for  data  packing 
and  unpacking  when  the  variable-length  and  repetition  features  of 
MODEL  are  used.  This  is  explained  after  the  example  below.  The 
procedure  creating  it  is  given  in  Algorithm  IDPACK  and  outlined  in  the 
next  section. 


An  example  of  an  entry  in  the  flowchart  table  which  corresponds 
to  a record,  from  the  MINSALE  problem,  is  for  SALEREC  which  is  the 
name  of  the  record  for  the  sales  transaction.  The  flowchart  table 
entry  for  SALEREC  would  appear  as  follows: 


I 
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I 
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which  indicates  that  SALEREC,  the  fifth  ordered  node,  is  the  name  of 
the  record  of  the  SALETRAN  file,  which  is  an  input  sequential  file  and 
from  which  SALEREC  is  to  be  read  (RD). 

A. 4. 3. 4 Identifying  Data  Packing  and  Unpacking  Information  for 
Variable  Repetition  and  Length 
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When  all  fields  of  a record  are  of  a fixed  length  and  occur  a 
fixed  number  of  times,  code  can  easily  be  generated  to  have  the  read 
or  write  command  transfer  the  data  directly  to  or  from  the  PL/1 
hierarchic  storage  structure,  which  represents  such  data  structures 
conveniently.  The  MODEL  language,  however,  has  facilities  to  describe 
variable-length  fields  or  variably-existing  groups  or  fields  (via  the 
LEN  or  EXIST  assertion  facilities)  whereby  the  user  can  provide 
expressions  to  be  evaluated  at  execution-time,  which  in  turn  determine 
the  length,  existence,  or  repetition  of  an  item.  Such  general 
facilities  for  variability  of  data  do  not  exist  in  PL/1  data 
structures.  PL/1  does  not  have  direct  facilities,  as  does  MODEL,  to 
define  the  length  of  a field  or  the  number  of  repetitions  of  a group 
or  field  by  an  aribtrary  expression,  such  as  by  an  arithmetic 
expression  or  by  a function  to  scan  for  a delimeter.  Also,  in  MODEL  a 
field  or  group  can  be  defined  to  be  optional  by  describing  it  to  occur 
a minimum  of  zero  times  with  an  associated  EXIST  assertion  defining 
the  number.  There  is  no  direct  way  to  declare  such  a concept  in  PL/1. 
PL/1  provides  a more  limited  variability  capability  with  the  REFER 
feature  (by  requiring  the  length  or  number  of  repetitions  to  be  stored 
explicitly  with  the  data  in  the  record),  and  "variable-length"  strings 
in  PL/1  (which  actually  occupy  the  maximum  length  and  store  current 
length).  Therefore,  generation  of  input/output  code  for  files  with 
such  variability  cannot  simply  transfer  the  data  directly  in  and  out 
of  the  PL/1  data  structure.  Instead,  the  generated  PL/1  code  nust 
simulate  the  variability  provided  by  MODEL.  Therefore,  whenever  a 
record  described  in  MODEL  has  variable  length  or  variably  existing 
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Items  (uses  the  MODEL  LEN  or  EXIST  assertions),  extra  code  Is  going  to 
be  generated.  The  actual  transformations  from  the  MODEL  data 
structures  to  those  available  In  PL/1  will  be  shown  in  the 
corresponding  code  generation  section  (4.5. 1.3). 

For  reading  such  variable  records,  the  input  buffer  must  be 
scanned,  evaluating  the  LEN  and  EXIST  assertions  when  they  cone  up, 
and  the  data  needs  to  be  transferred  field-by-field  into  the  PL/1 
structure.  The  information  about  variable  data  within  the  record,  if 
any,  that  is  necessary  for  such  variable  data  "unpacking"  operations 
is  identified  in  the  current  flowchart  table  entry  (in  the  "Packlnf" 
segment  above)  for  later  code  generation. 

For  writing  such  variable  records,  the  data  in  the  output  PL/1 
data  structure  must  be  extracted  for  the  exact  length  or  existence  as 
evaluated  by  the  assertions,  and  transferred  to  the  output  buffer. 
Such  variable  data  "packing"  information  within  the  record  are  also 
identified  here  for  later  code  generation. 

Algorithm  IDPACK  shows  the  procedure  for  identifying  the 
necessary  Information  for  later  code  generation.  The  data  structures 
used  and  generated  by  this  algorithm  are  discussed  here.  Identifying 
the  variable  information  here  involves  a recursive  routine  to  "climb" 
down  the  tree  structure  of  the  record  and  identify  those  items  which 
have  a variable  length  or  existence.  The  algorithm  stacks  information 
in  a temporary  stack  (TEMP-STACK)  about  each  member  of  the  record 
(field,  group,  and  in  turn  its  sub-members),  as  it  climbs  down  the 
record  tree-stucture  (Step  2).  The  information  about  each  member  of 


Algorithm  IDPACK:  Identify  Data  "Packing"  and  "Unpacking"  Information 
for  Variable  Repetition  and  Length 


Step  1.  For  each  member  (group  or  field)  of  the  record,  perform  Step 

2. 

Step  2.  Call  CRF.ATE-TEMP  (member-name,  rfsubs,  subl,sub2) 

(a  recursive  procedure  to  enter  packing  information  for  all  data  items 
in  the  record  into  the  flowchart  table  entry). 

name  --  name  of  group  or  field  in  record. 

#subs  — 0 subscripts  means  no  repetition; 

1 subscript  means  fixed  number  of  repetitions; 

2 subscripts,  variable  no.  of  repetitions, 
subl  — minimum  number  of  repetitions 

sub2  — maximum  number  of  repetitions 

(subl«sub2  implies  fixed  number  of  repetition). 

Step  3.  Copy  TEMP-STACK  (created  by  CREATE-TEMP  subroutine)  into  the 
PACKINF  segment  of  flowchart  table  entry. 


Step  4 


Return 
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Algorithm  IDPACK  (~ontinued ) : Subroutine  CREATE-TEMP 

(Subroutine  to  create  information  for  each  sub-member  (group  or  field) 
of  the  record  to  be  entered  in  the  PACKINF  segment  of  the  flowchart 
table  entry) 


Step  1.  Set  NAME,  ^SUBSCRIPTS,  SUB1,  SUB 2 (to  become  part  of  the 
PACKINF  segment  of  the  flowchart  table  entry)  according  to  passed 
parameters. 

Step  2.  If  member  is  a field,  then  go  to  Step  3;  else  go  to  Step  12. 
Step  3.  Set  TYPE  -'F'  (field). 

Step  4.  Set  ARITY  “0  (field  has  no  sub-members). 

Step  5.  RETRIEVE  field  storage  entry. 

Step  6.  Set  FIELD-TYPE  to  'C',  'B',  'F',  or  'N'  according  to  whether 
field  is  character,  binary,  fixed  decimal,  or  numeric  character, 
respectively. 

Step  7.  If  field  is  fixed-length,  then  set  FIELD-LEN-TYPE  to  'F';  else 
set  it  to  'V'  (variable-length). 

Step  8.  Set  MIN-LENGT11  and  MAX-LENGTH  according  to  field  storage 
entry. 

Step  9.  If  field  repeats  variable  number  times  (#SUBS“2),  RETRIEVE 
EXIST  assertion  name  evaluating  repetitions  & save  in  EXIST-PROC. 

Step  10.  If  field  is  of  variable  length,  RETRIEVE  name  of  LEN 
assertion  that  evaluates  it,  and  set  LEN-PROC  to  it. 

Step  11.  Go  to  Step  15. 

Step  12.  (member  is  a group):  RETRIEVE  group  storage  entry; 

If  group  repeats  a variable  number  of  times  (#subs*2)  then  RETRIEVE 
name  of  the  EXIST  assertion  that  evaluates  repetition  and  save  in 
EXIST-PROC. 

Step  13.  Set  ARITY  ■*  number  of  sub-members  of  group;  fill  in  SUB  1 and 
SUB 2 (minimum  and  maximum  repetitions). 

Step  14.  For  each  sub-member  of  group,  call  CREATE-TEMP  recursively 
with  parameters  (name,  Hsubs,  subl,  sub2),  stacking  the  above 
information  for  each  level  in  the  record  tree-structure  onto  TEMP- 
STACK  . 

Step  15.  Return. 


the  record  in  TEMP-STACK  is  put  into  the  PACKINF  portion  of  the 
"Record"  flowchart  table  entry  depicted  above  (Step  3).  The  PACKINF 
segment  of  the  flowchart  table  entry  has  the  following  information  for 
each  member  (group  or  field)  of  the  variable  record,  created  by  the 
CREATE-TEMP  subroutine  in  the  algorithm.  The  CREATE-TEMP  subroutine 
fills  in  this  information  for  each  member,  be  it  a field  (Step  3-11) 
or  a group  (Steps  12-14).  In  the  case  of  groups,  the  subroutine  is 
called  recursively  for  its  sub-members. 

NAME  — name  of  member  (group  or  field) 

TYPE  — 'F'  for  field;  'C'  for  group. 

^SUBSCRIPTS  — 0»no  repetition;  l“fixed  number  of 
repetitions;  2«  variable  number  of  repetitions. 

SUB1  — minimum  number  of  repetitions. 

SUB2  — maximum  number  of  repetitions  (for  fixed  repetition, 
SUB1-SUB2). 

EXIST-PROC  — name  of  EXIST  assertion  evaluating  number  of 
repetitions. 

ARITY  — number  of  sub-members. 

FIELD-TYPE  — C for  character;  B for  binary;  F for  fixed 
decimal;  N for  numeric  character. 

FIELD-LEN-TYPE  — F for  fixed;  V for  variable. 

MIN-LENGTH  --  minimum  length  of  field. 

MAX-LENGTH  — maximum  length  of  field  (MIN -LENGTH "MAX -LENGTH 
for  fixed  length). 

LF.N-PROC  — name  of  LEN  assertion  evaluating  length  of  field. 
From  this  information,  code  can  be  generated  later  to  transfer  the 
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"variable"  data  in  and  out  of  the  object  PL/1  hierarchical  data 
structure  (see  corresponding  sections  in  code  generation  on  i/o  and 
variability). 


An  example  of  an  entry  generated  in  the  flowchart  table  for  the 
variable- length  record  SALEREC  from  the  DEPSALE  problem  is  the 
following: 


~~4-  — — ' 1 4 ♦ — — 


|Node# 

I 

-j 

I 

1113 

I 

I 


I I 

Node type |Recnm|10mode 

I I 


I I 

RECD  | SALE  |RD 

I I 

|REC  | 


Flname |Org 

I 


TRANS  |S 


Keyed 


I 

Keynm|PackInf 

I 
I 

— | (see 

I 

Ibelow) 


-4_ 


4. 4. 3. 5 Identifying  Assertions  Information 


The  routine  "Identify  Assertion  Information"  (IDASSN)  has  the 


task  of  collecting  all  the  information  necessary  in  order  to  generate 


later  a PL/1  procedure  to  carry  out  the  operations  implied  by  the 


assertion  and  to  generate  a CALL  to  that  procedure.  This  routine  is 


invoked  from  the  "Generate  Flowchart  Table"  control  routine  (GENFLT) 


and  has,  as  input,  a dictionary  entry  of  the  assertion  for  which  code 


is  being  generated. 


■ 


* vfteMKflp£. 
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Algorithm  IDASSN  presents  the  Identify  Assertions  procedure.  It 
retrieves  the  text  of  the  assertion  (Step  2),  collects  it,  and 
reformats  it  without  extraneous  spacing.  Besides  entering  the  name  and 
text  of  the  assertion  in  the  flowchart  table  entry  (Step  2),  it  also 
enters  information  for  several  special  cases:  if  the  assertion  uses  a 
function,  it  marks  the  use  of  the  function  in  a table  so  that  the 
function  itself  be  included  in  the  generated  program  (Steps  3-4).  As 
explained  further  below,  if  the  assertion  uses  a "conditional" 
function,  the  conditional  function  is  entered  in  the  "conditional 
list"  so  that  conditional  control  code  can  later  be  generated  (Step 
6).  Also  explained  further,  if  the  assertion  uses  the  "Replace" 
function,  then  the  target  of  the  replacement  is  entered  in  the 
flowchart  table  entry  so  that  the  later  PL/1  code-generation  routine 
will  be  able  to  generate  replacement  code  (Step  5).  Further  comments 
on  how  code  is  generated  for  replacement  are  given  below  under  the 
explanation  of  RPLAB  and  in  the  corresponding  code  generation  section 
(4.5. 1.  7). 

The  language-independent  Information  which  is  later  used  to 
generate  the  PL/1  procedure  embodying  the  assertion  and  its 
invocation,  and  any  necessary  PL/1  control  code  to  govern  the 
procedure  execution  is  put  into  an  entry  of  the  flowchart  table 
(FLOWTAB_ASSN)  which  has  the  following  format: 
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Algorithm  IDASSN:  Identify  Assertion  Information 


[Subroutines  called:  RETRIEVE] 


Step  1.  RETRIEVE  assertion  storage  entry. 

Step  2.  Fill  in  text,  node#,  type,  and  name  of  assertion  in  the 
flowchart  table  entry. 

Step  3.  If  assertion  uses  a function,  then  go  to  Step  4;  else  go  to 
Step  7. 

Step  4.  Mark  use  of  function  in  USEFCN  table  (so  that  the  function 
itself  later  will  be  Included  in  the  generated  program). 

Step  5.  If  assertion  uses  the  Replace  function,  then  save  replacement 
target  in  the  flowchart  table  entry. 

Step  6.  If  assertion  uses  a conditional  function,  then  add  the 
assertion  to  the  "conditional  list"  (used  later  to  generate  code  to 
circumvent  dependent  nodes). 

Step  7.  If  assertion  specifies  a source  subset,  then  generate  a 
flowchart  table  entry  to  go  read  the  next  record  if  the  current  record 
is  not  in  the  subset. 

Step  8.  Write  flowchart  table  entry. 


Step  10.  Return 


NODE#  is  the  number  of  the  assertion  node  as  given  by  the  order 
vector. 

NODETYPE  is  set  to  'ASSN'  in  order  to  indicate  the  type  of 
flowchart  entry. 

■ 

ASSN  NAME  is  the  name  of  the  assertion  for  which  code  is  being 
generated. 


FCN  is  the  name  of  a system-provided  function,  if  any,  that  is 
used  by  the  assertion.  If  the  specification  uses  any  system-provided 
function,  the  use  of  such  a function  is  marked  by  the  FCNUSED  routine 
so  that  it  will  be  included  in  the  generated  program  later  (by  the 
MERGPL1  routine).  Some  functions  provided  by  the  system  are  not 
"completed"  immediately  upon  invocation  but  only  when  an  associated 
condition  is  met.  In  other  words,  some  functions  can  have  conditions 
associated  with  them  which  signal  their  completion.  Such  a mechanism 
turns  out  to  be  a useful  and  general  facility.  It  applies  only  to 
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indication  of  the  use  of  such  a function  in  the  flowchart  entry  here 
becomes  necessary  for  the  code-generation  phase  in  order  to  generate 
conditional  control  code  to  test  for  the  node's  completion.  In  order 
to  determine  whether  a certain  function  is  completed  conditionally, 
this  routine  can  check  the  weighted  adjacency  matrix  for  the 
conditional  code  as  filled  in  earlier  and  can  access  a system  table  of 
all  such  conditional  system-provided  functions  SYSFCN.  The  system 
function  itself  is  responsible  for  setting  a flag  at  execution-time 
when  the  function  is  considered  complete.  This  provides  a general 
mechanism  for  implementing  such  a concept.  The  corresponding  code 
generation  routine  is  responsible  for  generating  code  to  test  for  the 
completion  flag  of  the  function,  and  thereby  flagging  the  completion 
of  the  assertion,  which  in  turn  triggers  the  execution  of  its 
successors.  (See  Section  4.5. 1.5  for  further  explanation  of  the  code 
that  enables  this  mechanism). 


In  cases  where  the  assertion  involves  a conditionally  completed 
function,  not  only  is  the  above  flowchart  table  entry  created,  but 
also  the  node  number  of  this  assertion  is  added  to  a "conditional 
assertions  list".  Such  a list  is  referenced  by  the  "check  conditions" 
subroutine  (CHECOHD),  which  is  called  by  the  Generate  Flowchart 
control  module  (GENFLT  already  described),  prior  to  generation  of  each 
subsequent  flowchart  entry.  The  conditional  assertions  list  is  checked 
in  order  to  generate  conditional  control  code  to  circumvent  any 
operations  that  depend  upon  the  completion  of  the  assertion.  The 
succeeding  nodes  which  may  depend  on  the  completion  of  the  conditional 
flowchart  table  entry  are  all  nodes  j such  that 
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where  1 Is  the  current  node  and  P is  the  path  matrix. 


i 


However,  problems  where  succeeding  nodes  depend  on  more  than  one 
conditional  function  will  need  special  care,  and  there  are  two  cases. 
If  a later  assertion  has  various  source  items  each  of  which  is 
dependent  on  conditional  functions,  then  the  condition  for  execution 
of  the  assertion  is  the  conjunction  of  completion  of  each  of  those 
conditional  functions  as  illustrated  in  the  following  diagram: 


where  Cl  and  C2  are  assertions  using  conditionally  completed 
functions.  If,  on  the  other  hand,  a later  assertion  has  a data  item  as 
source  which  depends  on  more  than  one  conditional  function,  this 
implies  that  the  functions  are  mutually  exclusive.  In  such  cases  the 
condition  for  execution  of  the  assertion  is  the  disjunction  (OR)  of 
the  completion  of  any  of  the  precedent  functions,  as  illustrated 
below: 


4* 


where  Cl  and  C2  are  assertions  using  conditionally  completed 
functions. 


In  order  to  generate  the  conditional  control  code  before  each 
descendant  node,  a flowchart  table  entry  of  the  following  form  is 
created  by  the  "check  condition"  (CHECOND)  routine.  Such  an  entry  is 
generated  before  each  node  that  is  a descendant  of  the  conditional 
function  placed  in  the  conditional  assertions  list: 

t t ~i~  ; 

| NODE#  | COND  | ASSN  NAME  | 

III  I 

Such  flowchart  table  entries  are  used  to  generate  the  PL/1  conditional 
transfers  (IF  statements)  later.  In  cases  of  dependencies  on  multiple 
conditional  functions,  adjacent  "IF's"  imply  conjunction  of  the  tests. 
For  cases  where  a disjunction  of  the  conditions  is  needed,  described 
above,  the  conditional  tests  need  to  be  separated  by  "or"s. 


.... 


Returning  to  the  flowchart  table  entry  for  assertions,  RPLAB 
(replace  label)  is  used  only  if  the  assertion  uses  the  system-provided 
REPLACE  function.  It  is  the  label  to  which  the  program  branches  after 
a replacement.  It  is  determined  by  looking  for  the  assertion  target  of 
the  REPLACE  in  the  dictionary  and  generating  a label  corresponding  to 
that  node  number.  The  REPLACE  feature  is  thus  implemented  as  a special 
type  of  iterative  loop  whose  starting  point  is  the  object  of 
replacement  and  whose  ending  point  is  the  assertion  starting  the 
replacement.  It  is  in  this  way  analogous  to  iterative  loops  Implied  by 
the  FOREACH  option  described  in  Section  4. A. 2.  It  would  have  been 
desirable,  although  not  indicated  here,  to  remove  from  this  loop  all 
nodes  that  do  not  depend  on  the  starting  node  by  moving  them  to  the 
point  preceding  the  "REPLACE"  loop  in  a manner  that  was  done  for 
iterative  loops. 

One  final  check  made  by  the  IDASSN  algorithm  is  to  test  whether 
or  not  the  assertion  is  a "SUBSET"  type  assertion  for  a source  file 
(Step  7);  that  is,  whether  the  assertion  is  describing  a condition 
under  which  a record  is  to  be  considered  for  the  module.  If  it  is  this 
type  of  assertion  (target  is  of  the  form  "SUBSET  .filename"),  then 
code  needs  to  be  generated  to  branch  to  read  the  next  record  if  the 
subset  condition  is  not  met.  This  is  indicated  in  the  flowchart  table 
here  as  a COHD  type  flowchart  table  entry  (like  the  one  depicted 
above)  and  a GOTO  type  entry  (like  the  one  described  in  Section 
4. A. 3. 9).  These  flowchart  entries  produced  here  represent  a 
conditional  branch,  and  will  correspond  to  the  code:  "IF  “SUBSET 
.filename  THEN  GO  TO  r",  where  r is  the  label  of  the  READ  for  the  next 
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record. 


r i 


The  code  generation  routine  that  corresponds  to  the  above 
assertion-description  entry  of  the  flowchart  table  will  have  the  task 
of  transforming  such  entries  into  PL/1  procedures.  That  code- 
generation procedure  "Generate  Procedure  Code"  (Section  4.5. 1.4)  will 
have  to  generate  the  procedure  itself  and  its  invocation,  and  any 


necessary  control  code,  such  as  for  replacement  and  stacking  when 
necessary.  Iterative  control  code  is  also  generated  when  necessary  for 
repeating  data  items  (see  Sections  4. 4. 3. 7 and  4.5. 1.6). 


An  example  of  an  assertion  entry  in  the  flowchart  table  from  the 
DEPSALE  problem  is  below,  and  corresponds  to  the  CALCCHRG  assertion: 

H -H ■*— >* ■« -4 + 

II  I III  I 

iNode#  | NodeType  | Assn  Name  |CondFcn|RepLab|Text  I 

! I ! ! ! | 


|4  | ASSN  | CALCCHRG  | — |—  |... 

II  I III 


[if 

\ ii 


This  indicates  the  assertion  entry  for  CALCCHRG,  which  does  not  use 
any  conditional  functions  nor  replacement. 


An  example  from  the  DEPSALE  problem  showing  a replace  label  is 
the  following: 


**  t Tmanm's 
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|Node#  | NodeType  | Assn  Name  | CondFcn |RepLab |Text 


|126  | ASSN  | TRYREFL  |—  |$L082  |... 


An  example  showing  a conditional  function  Is  given  In  the 
corresponding  code  generation  section  (4.5.  1.5). 

| 

■ 

4. 4.3. 6 Identifying  Field  Associations 

The  routine  "Identify  Field  Associations"  (IDFLDAS)  Is  Invoked  by 
the  "Generate  Flowchart  Table"  routine  whenever  the  current  node  Is  a 
field  to  check  the  weighted  adjacency  matrix  for  possible  implicit 
assignments. 

Algorithm  IDFLDAS  shows  the  Identifying  Field  Associations 
procedure  and  its  generation  of  the  flowchart  table  entry  described 
below.  The  algorithm  checks  the  column  of  the  weighted  adjacency 
matrix  corresponding  to  the  field  in  question  in  order  to  check  the 
type  of  predecessor  which  the  field  has  (Steps  2-5). 

If  a field  is  a member  of  a source  record,  no  further  code  will 
have  to  be  generated,  because  the  field  has  a record  or  group 
predecessor  and  a value  from  the  associated  input  command.  Therefore, 
only  a dummy  flowchart  table  entry  (of  type  FLDS)  is  created  here  with 
only  its  name  for  documentation  purposes.  A flowchart  entry  is  created 
in  any  case  so  that  all  nodes  have  a corresponding  entry  in  the 


‘V 


I 
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Algorithm  IDFLDAS:  Identifying  Field  Associations 


Step  1.  Fill  flowchart  table  entry  with  node  number,  j. 

Step  2.  (check  column  of  weighted  adjacency  matrix  for  source  of  field 
or  interim;  steps  2 through  5): 

Set  i“l. 

Step  3.  If  Mij>0  then  go  to  Step  6. 

Step  4.  Set  i*l+l. 

Step  5.  Go  to  step  3. 

Step  b.  Set  Node  Type  (in  flowchart  table  entry)  to  a code  depending 
on  the  predecessor  as  follows: 

Case  1:  If  type  is  Field  6 Mij>*l  (source  record),  then  Set  Node  Type= 
FLDS  . 

Case  2:  If  type  is  Field  & Mij«3  or  7 (explicit  value),  then  Set  Node 
Type=  FLDP  . 

Case  3:  If  type  is  Field  & Mij«4  (implicit  value),  then  Set  Node  Type= 
FLDI  . 

Case  4:  If  type  is  Interim  & Mij“3  or  7 (explicit  value),  then  Set 

Node  Type**  INTP  . 

Case  5:  If  type  is  Interim  & Mij«4  (implicit  value),  then  Set  Node 
Type-  INTI  . 

Step  7.  For  Cases  3 and  5 above,  enter  the  implicit  source  field  in 
the  flowchart  table  entry. 

Step  8.  Check  attributes  of  assigned  fields  for  compatibility. 

Step  9.  Return. 
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flowchart  table. 

If  the  field  is  a member  of  a target  record,  then  it  may  also 
already  have  a value,  by  virtue  of  its  being  the  target  of  an 
assertion  which  has  that  field  as  a successor  and  generates  that 
value ; tfi  )(Mij*3)  where  J is  the  node  number  of  the  field.  In  such  a 
case,  too,  no  further  code  need  be  generated,  and  therefore  only  a 
dummy  flowchart  table  entry  is  created  (of  type  FLOP)  for 
documentation.  This  routine  can  easily  check  whether  the  field  has  an 
explicit  value  by  virtue  of  being  the  target  of  an  assertion,  by 
checking  the  corresponding  column  within  the  weighted  adjacency  matrix 
(Step  2-6). 

If,  on  the  other  hand,  the  adjacency  matrix  indicates  that  the 
field  has  an  implicit  source,  [ (3l)(Mij-A)  where  j is  the  node  number 
of  the  field  ],  then  a flowchart  table  entry  (of  type  FLDI ) needs  to 
be  created  and  will  later  be  used  to  generate  an  assignment  of  the 
value  to  the  field  (Step  6,  Cases  3 and  5;  Step  7).  Recall  that  the 
implicit  source  of  the  field  was  determined  by  the  "Find  Implicit 
Source"  routine  (Section  A. 3, 2. 3. A)  in  the  absence  of  explicit 
assertions.  This  includes  correspondence  of  fields  by  such  information 
as  identical  names  and  by  keywords  such  as  OLD  and  NEW.  In  such  cases, 
a flowchart  table  entry  of  the  following  form  is  created: 


I NODE#  | NODETYPE  | TARGET  FIELD  |IMPLICIT  SRC  FLD | 


where 


NODE#  is  the  number  of  the  node  of  this  field  as  given  by  the 
order  vector; 

NODE  TYPE  is  set  to  'FLDI'  to  indicate  that  a field  assignment 
code  will  need  to  be  generated; 

TARGET  FIELD  is  the  name  of  the  field  being  assigned  a value; 

IMPLICIT  Source  Field  is  the  name  of  the  implicit  source  to  this 
field. 

The  corresponding  code  generation  routine  will  be  able  to 
generate  the  corresponding  PL/1  assignment  statement  of  the  form: 
target  field  ■ implicit  source  field; 

An  example  of  a flowchart  table  entry  for  an  implicit  assignment 

» 

from  the  DEPSALE  problem  is  the  following: 

H 1 +- + 


| NODE#  | NODETYPE  | TARGET  FIELD  |IMPLIC1T  SRC  FLD  | 


I 32  | FLDI  | JOURN.CUST#  |TRANS.CUST# 
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4. 4. 3. 7 Checking  for  Iterations 

As  explained  in  Section  4.4.2  on  scope  and  iteration  analysis  and 
optimization,  a table  (DOTAB)  of  beginning  and  ending  statements  to  be 
included  in  each  iteration  is  created.  Upon  each  loop  through  the 
order  vector  a routine  is  called  (CHECKDO)  to  check  the  iteration 
table  to  see  whether  this  is  the  starting  statement  of  an  iteration. 


and  if 

so, 

a "DO-type" 

flowchart  table  entry  is  created  with 

following 

format : 



4 

III  1 

|Node# |Type | FOREACH  name|Upper  Type 
ill  l 

1 

|Upper# 

1 

i i 

|Upper  Name  | 
t 1 

1 

i 

1 

1 

1 

i i 

_L.  _ 1 

T- 

1 

| n 
1 

i 

|D0 

1 

r 

(Iteration 

l 

1 

1 F*f ixed 
1 

1 

| if  "F" 
1 

~T 

1 1 

, lif  "v",  | 

1 1 

1 

i 

I 

1 

1 

| 

(Variable 

i 

1 

1#  times 
1 

1 V«varying 
1 

1 1 1 

|#  times  | EXIST  name  | 

i i i 

J 

i 

1 

I 

1 

1 

1 

i 

1 

i 

1 

1 1 

| contains  # | 
1 1 

1 

i 

1 

1 

1 

I 

l 

i 

1 

|#  times 
1 

1 

i 

1 

1 1 

|of  times  | 

1 1 

1 

i _ _ 

1 

1 

l 

4— 

1 

1 1 

-L  - J. 

T*-"* 

From 

this 

flowchart 

table  entry. 

a PL/1 

DO  iterative  statement 

generated  later  by  the  corresponding  code  generation  routine. 
Algorithn  CHECKDO  shows  the  process  that  generates  the  table  entry. 
Likewise,  the  ending  statement  of  an  iteration  is  checked  by  the 
CHECEND  routine,  and  if  the  most  recent  statement  is  the  last  one  of 
an  iteration,  then  an  "END-type"  flowchart  table  entry  is  generated 
(by  Algorithm  CHECEND)  with  the  following  format: 


mnonpqHl 
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Algorithm  CHECKDO:  Check  "Do-loops" 

(Input  data  structure  is  DOTAB  already  described  in  Section  4.4.2; 
output  data  structure  Is  the  flowchart  table  entry  described  In  this 
section) . 

Step  1.  If  there  are  no  more  entries  in  DOTAB  table,  then  return. 

Step  2.  If  the  node  number  indicated  in  DOTAB  not  m current  node 
number,  then  return. 

Step  3.  Create  flowchart  table  entry  for  iteration  (depicted  in  text). 

Step  4.  Fill  entry  with  (a)  current  node  number,  (b)  "DO"  type,  and 
(c)  iteration  variable  (from  DOTAB). 

Step  5.  Retrieve  type  of  iteration  (fixed  or  variable  number  of  times) 
and  fill  in  F or  V respectively  in  entry  as  depicted. 

Step  6.  Fill  in  number  of  repetitions  (if  fixed)  or  EXIST  name  (if 
variable) . 

Step  7.  Examine  next  entry  in  DOTAB;  go  to  Step  2 (possible  beginning 
of  other  iterations). 


Algorithm  CHECEND:  Check  for  Generation  of  "END" 

Step  1.  If  there  are  no  more  entries  in  DOTAB  then  return; 


Step  2.  If  the  node  number  Indicated  in  DOTAB  not  = current  node 
number,  then  return. 

Step  3.  Generate  "END"  flowchart  table  entry  as  depicted. 

Step  4.  Examine  next  entry  in  DOTAB  then  go  to  Step  2 (possible  end  of 
other  iterations). 


i,  i jji.im  iwq 


"" 
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i 

1 Node# 
1 

_| 

1 1 

| Node  Type  | 
1 1 

► 

1 

1 

1 

* 

i 

1 1 

“T 

i 

1 n 
1 

H 

| END  | 

1 1 

i 

i 

+ 

to  represent  the  end  of  the  Iteration. 


An  example  of  such  entries  for  an  iteration  from  the  DEPSALE 
problem  are  the  following: 

T T T T I 

iNode# [Type | FOREACH  name|Upper  Type  |Upper#  |Upper  Name  | 

! -L  1 |_  11  | 


iii  i it  i 

1112  |D0  | FOREACH-TRITEM  V |—  | EXIST.  TR  ITEM 


i 

1 Node# 
1 

(— 

I Node  Type 

1 

1 

1 

1 

1 

1 

A 

r 

i 

| 21 
1 

4— ■ 

| END 

t— 

1 

1 

1 

-+— 

T 

i 

i 

i 

I 


4. 4.3. 8 Checking  for  Label  Generation 


As  noted  earlier,  for  example  in  the  case  of  replacement. 


statement  labels  which  are  referenced  are  generated  occasionally  by 


putting  them  in  a "label  table".  As  the  GENFLT  control  routine  loops 


through  the  order  vector,  it  invokes  the  "Check  label"  routine 


(CHECLAB)  to  check  the  label  table  to  see  whether  any  label  needs  to 


be  generated  for  the  current  statement. 


If  so,  a flowchart  table  entry  with  the  following  format  is 


generated  by  the  CHECLAB  Algorithm: 


| Node#  | Node  Type  [Label  Name| 


I LAB 


This  is  used  by  the  corresponding  code  generation  routine  to 


generate  a PL/1  statement  label. 


An  example  from  the  DEPSALE  problem  is  for  the  label  referenced 


for  replacement: 


• • ' - : ■ 
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Algorithm  CHECLAB:  Check  for  Labels 

(Input  data  structure:  "label  table",  the  table  of  labels  to  be 
generated) 

Step  1.  Iterate  through  "label  table",  performing  Step  2 for  each 
entry;  return. 

Step  2.  If  current  node-node  to  be  labeled,  then  create  flowchart 
table  entry  for  label  as  depicted. 


| Node#  | Node  Type  |Label  Name | 

I II 

II  II 

I 82  | LAB  | $L082  | 

II  II 


The  label  name  is  formed  by  a '$L'  concatenated  with  the  node  number 
(82  in  this  example)  of  the  node  receiving  the  label. 


**  M&TM masm* 
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4. 4. 3. 9 Identifying  Housekeeping  and  End-of-Program  Tasks 


At  the  end  of  generation  of  flowchart  entries  for  all  the  nodes 
of  the  order  vector,  there  still  remains  some  "housekeeping"  code  to 
be  generated.  Control  code  is  needed  to  branch  to  process  the  next  set 
of  records.  This  is  accomplished  by  generating  a "GOTO-type"  flowchart 
entry: 


I Node#  | Node  Type  |Name 


where  x is  the  label  (saved  by  IDIOCD)  which  starts  the  program. 


An  example  from  the  DEPSALE  problem  which  branches  back  to  read 
the  next  transaction  is  the  following: 

T T I 

I Node#  | Node  Type  |Label  Name | 


| $RD-TRANS 


+ 


\ u 

; r*; 


Before  branching  back,  however,  several  events  are  required. 
Specifically,  all  the  CHOICE  variables,  conditional  flags,  and 
replacement  flags  must  be  reset  so  that  they  can  be  set  again  in  the 
next  cycle.  This  is  accomplished  by  generating  "reset-type"  flowchart 
entries  of  the  form: 


1 ■■X&MBl 
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r r r ; 

| Node#  | Node  Type  |Name  | 

II  II 

-I "• 1- 

II  II 

| | RSET  | x | 

II  II 

H ^ +_ + 

where  x is  the  flag  or  switch  being  reset.  Note  that  variables 
associated  with  functions  (such  as  total  variables)  are  not  reset 
automatically  here,  but  rather  by  the  function  itself  upon  completion. 

An  example  of  a "reset"  flowchart  table  entry  from  the  DEPSALE 
problem  is  the  following: 

r r t i 

| Node#  | Node  Type  |Name  | 

I II 

II  II 

| | RSET  | CHOICE. SALE 

II  II 

which  resets  the  CHOICE  name  SALE. 

An  "end-type"  flowchart  entry  is  also  generated  to  mark  the  end 
of  the  program. 


Algorithms  IDGOTO  and  IDRSET  consist  simply  of  code  to  generate 
these  two  kinds  of  entries  respectively,  and  are  therefore  omitted. 


* T 


•-jewr 
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4. A. 3. 10  The  Flowchart  Table  Report 

The  entries  of  the  flowchart  table  are  formatted  and  printed  out 
by  this  routine,  "Generate  Flowchart  Report"  (CFLTRPT),  so  that  a 
system  programmer  or  interested  user  of  MODEL  could  check  the  flow  of 
the  generated  program.  Each  entry  of  the  flowchart  table  is  accepted 
by  this  routine  as  input.  After  branching  on  the  flowchart  entry  type, 
it  produces  a report  with  a line  corresponding  to  each  entry  as 
output.  A schema  of  each  kind  of  line  of  the  report  is  given  in  Figure 
4.16a  and  a sample  flowchart  report  appears  in  Figure  4.16b.  Each 
entry  contains  the  following: 

the  NODE  NUMBER,  which  is  the  same  as  in  the  flowchart  table; 
the  NAME  of  the  item  at  that  node,  if  any; 
a DESCRIPTION  of  the  node;  and 

the  EVENT  to  be  performed  (an  English  summary  of  the  PL/1 
statements  at  that  node). 


4.4.3.11  Generating  Table  of  Data  Structures  Declarations 

Just  as  a language-independent  table  is  generated  to  represent  a 
flowchart  of  the  executable  portion  of  the  object  program,  this 
routine  generates  a table  of  all  the  variables  and  attributes  for 
vdiich  PL/1  declarations  will  have  to  be  generated.  Generating  the 
necessary  declarations,  then,  is  a two-step  process,  as  shown  in 
Figure  4.17.  This  first  routine,  "Generate  Declarations  Table" 
(GDCLTAB)  accepts,  as  input,  the  stored  MODEL  data  descriptions,  and 
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iNode# iNode  Type  (Description 

4 H *■ 

| Iraodule(MODL) (Module  Name 

i i i 

lEvent 

|Proc  Heading 
| 

+ 

i 

+ 

i 

i 

i 

l 

i 

(file 

| FILE 

I 

1 
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1 

i 

1 

i 

i 

i 

i 

i 

i 

l 

i 

1 record (RECD 
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1 

1 

1 

IRECORD 

1 

1 

1 

1 

i i 
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(Parameters) 

1 

i 
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1 
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1 

I 

i 

| 
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i 

i 

i 

i 

l 

1 

| f ield(FLD) 

1 

1 

1 

1 

i 

| FIELD: 

I target  of  assert.  A 
| implicit  assign. 

| in  source  record  x 
1 

1 

1 
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| 

i 

i 

i 

i 

1 

i 

i 

I 

1 
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j (INTR) 

1 

| INTERIM 
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1 

1 

| (same) 

1 

| 

1 

i 

i 

i 

i 

i 

i 
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| (assn) 

1 

1 

1 

| ASSERTION 
1 
1 
1 
1 

1 

|CALL  assertion 
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|then  indicates 
| "repl  to  x") 

1 

i 

1 1 

1 

i 
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l 

1 

| storage(CARD 
j DISK, TAPE) 

I 
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1 

1 

1 
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|GOTO 
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1 
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1 

(ITERATION 
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1 
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|END 
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(END  OF  ITERATION 
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i 
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1 
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(LAB 

1 

1 
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i 

1 (X): 
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1 

i 

1 

|RSET 

1 

| RESET  FLAGS 
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|r-0 

i 
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Figure  4. 16a 

Flowchart  Table  Report  Entry  Types 
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produces,  as  output,  a table  with  an  entry  representing  each  name 
declaration  that  will  be  generated.  Secondly,  this  language- 
independent  table  representation  can  be  transformed  later  into  data 
structure  declarations  in  languages  such  as  PL/1  or  COBOL.  In  our 
case,  this  table  will  be  used  later  by  the  "Generate  PL/1 
Declarations"  routine  (Section  A. 5.  1.9),  which  will  transform  each 
table  entry  into  part  of  the  PL/1  hierarchic  data  structure 
declarations. 

As  before,  the  reason  for  the  two-step  declaration  generation  is 
modularity  and  the  capability  to  generate  object  data  structures  other 
than  PL/1  at  some  future  implementation  with  a minimum  of  change. 

In  order  to  generate  the  proper  declarations,  the  declarations 
generating  routine  will  have  to  know  the  characteristics  of  each  file, 
its  component  records  structure,  groups,  and  fields.  The  format  of  the 
Declarations  Table  entries  produced  by  the  current  routine  (Generate 
Declarations  Table)  are  presented  in  the  following  chart  in  Table  4.8. 
Each  schema  here  is  a type  of  entry  in  the  Declarations  Table  which, 
in  turn,  represents  a name  to  be  declared  in  the  generated  program. 
The  table  entry  contains  the  following: 


(1)  the  name  being  declared; 


Table  4.  8 Data  Declarations  Table 
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(2)  the  type  of  name; 

(3)  the  "level"  within  the  object  hierarchic  data  structure  (with 
the  file  name  at  the  top,  record  name  second,  and  groups  and  fields 
below  that);  and 

(4)  other  information  necessary  for  the  declaration,  as  indicated 
in  Table  4.8. 

A FILE  declaration  gets  two  entries  in  the  table.  The  first 
(described  in  the  table  as  type  'FL')  has  the  indicated  suffix 
(described  in  Section  4.4. 3. 3)  added  to  the  file  name  as  given  by  the 
user.  This  is  the  name  that  will  be  used  to  declare  the  external  file 
for  later  use  by  the  PL/1  compiler  and  the  operating  system,  and  the 
file  name  referenced  by  the  generated  input/output  statements.  The 
entry  conveys  a unique  name  for  the  file,  the  file  input/output  mode, 
and  the  file  organization.  The  suffix  is  added  in  the  first  entry  to 
distinguish  it  from  the  second  type  of  entry  for  files  (described  in 
the  table  as  type  'FR')  which  has  the  file  name  as  given  by  the  user. 
The  second  file  name  is  used  for  the  declaration  of  the  highest  level 
in  the  PL/1  hierarchic  data  structure.  The  reason  for  the  two  names 
(already  explained  in  Section  4.4. 3. 3)  is  that  the  user  can  qualify 
field  names  by  using  the  name  of  the  file  containing  them.  For 
example,  if  a file  named  INVEN  has  a field  named  STOCK/1  within  it, 
then  making  the  original  file  name  the  name  of  the  hierarchic  tree- 
structured  buffer  allows  the  field  to  be  referred  to  by  the  user  as 
INVEN. STOCK#  (to  distinguish  it  from  the  same-named  field  in  other 
files). 
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The  RECORD  declaration  also  gets  two  entries  in  the  table.  The 
first  (denoted  in  the  table  as  type  'RC')  contains  information  on  the 
length  and  type  of  record  for  the  declaration  of  a buffer  string 
within  the  area  of  the  generated  PL/1  program,  which  is  used  by  the 
I/O  operations.  The  name  of  this  buffer  is  formed  as  the  name  of  the 
record  with  '-s'  concatenated  to  distinguish  it  from  the  record  name 
as  given  by  the  user.  The  second  entry  for  a record  has  the  name  as 
given  by  the  user.  This  name  will  be  used  as  the  second-highest  level 
of  the  PL/1  hierarchic  data  structure  (after  the  file  name).  This 
allows  the  user  to  qualify  a field  name  alternatively  by  the  name  of 
the  record  it  is  in. 

The  CROUP  declaration  entry  needs  the  name  and  level  of  the  group 


and  the  number  of  repetitions  if  any. 

The  FIELD  declaration  entry  contains  all  the  information  that 
will  be  needed  to  declare  the  field  at  the  indicated  level  of  the 
hierarchic  structure.  This  includes  the  length  and  field  type 
attributes  indicated  in  the  chart. 

These  table  entries  are  created  by  the  "Generate  Declarations 
Table"  algorithm  (GDCLT).  It  retrieves  each  file  description  (Steps  1- 
3),  and  for  each  file's  record  description,  the  flowchart  table  entry 
for  the  record  string  buffer  is  generated  (Subroutine  FREC).  The  table 
entries  for  the  record  component  groups  and  fields  are  generated  by 
recursively  "climbing"  down  the  tree-structure  of  the  data  structure 
implicit  in  the  stored  MODEL  data  description  statements  (Subroutine 
FORM-TREE).  Furthermore,  this  routine  links  together  the  Declaration 
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Algorithm  GDCLT : "Generate  Declaration  Table" 

Variable  names  used  in  this  algorithm: 

Declaration  Table:  depicted  in  Table  4.8 

SOURCE-ARRAY:  array  to  hold  names  of  files  that  are  source  only. 

TARGET-ARRAY:  array  to  hold  names  of  files  that  are  target  only. 

SOURCE-TARCET-ARRAY:  array  to  hold  names  of  files  that  are  both 
source  and  target 

S:  stores  name  of  each  source-only  file 
T:  stores  name  of  each  target-only  file 

ST:  stores  name  of  each  file  that  is  both  source  and  target 


Step  1.  Retrieve  all  source-only  file  names  and  put  into  SOURCE-ARRAY 

Step  2.  Retrieve  all  target-only  file  names  and  put  into  TARGET-ARRAY 

Step  3.  Retrieve  all  source-and-target  file  names  and  put  into  SOURCE- 

TARGET-ARRAY 

Step  4.  For  each  source-only  file  name  in  SOURCE-ARRAY  (call  it  S): 

Generate  both  file  entries  (as  depicted  in  Table  4.8). 

Call  FREC(l) 

Call  FORM-TREE (S, 1) 

Step  5.  For  each  target-only  file  name  in  TARGET-ARRAY  (call  it  T): 

Generate  both  file  entries  (as  depicted  in  Table  4.8). 

Call  FREC(2 ) 

Call  FORM -TREE (T, 1 ) 

Step  6.  For  each  source-and-target  file  name  in  SOURCE-TARGET-ARRAY 
(call  it  ST): 


Generate  both  file  entries  (as  depicted  in  Table  4.8). 
Call  FP.EC(l) 

Call  FREC(2 ) 

Call  FORM-TREE (ST, 2) 

Step  7.  Return. 
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Algorithm  CDCI.T  : Subroutine  FREC(I-O-COnE) 

(forms  declarations  table  entries  for  records  string  buffer) 

Parameter  I-O-CODE:  indicates  whether  file  is  source  or  target 

(l-input,  2**output) 

Step  1.  Create  table  entry  with  name  and  type  as  depicted  in  Table 
4.8. 

Step  2.  Retrieve  record  name  and  if  corresponding  file  is  both  Source 
and  Target,  modify  the  record  string  name  with  prefix  'OLD_'  or  'NEW_' 

Step  3.  Retrieve  record  length  and  type  and  fill  in  table. 

Step  4.  Return. 

Subroutine  FORM-TREE (NAME, LEVEL) 

(recursive  routine  to  generate  table  entries  representing  hierarchical 
record  structure): 

parameters:  name  — data  name  being  declared 
level  — level  in  the  tree 

Step  1.  If  name  type  is  FLD  then  generate  table  entry  for  fields  as 
depicted;  return. 

Step  2.  Create  table  entry  for  current  level  in  tree  (file,  record,  or 
group  as  in  Table  4.8) 

Step  3.  Retrieve  all  sub-members  of  current  level  name. 

Step  4.  For  each  sub-member  (call  it  X)  call  FORM-TREE (X,LEVEL+1 ) . 
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4. 5 Code  Generation 

This  phase  of  the  Processor  proceeds  after  specification 
analysis,  precedence  determination,  program  design,  and  flowchart 
creation  have  been  completed.  Recall  that  had  there  been  user  errors 
during  syntax  analysis  or  specification  analysis,  then  neither  the 
flowchart  creation  nor  the  code-generation  phases  would  be  reached.  As 
seen  in  Figure  4. 18,  the  code  generation  phase  accepts  as  input  the 
flowchart  table  and  the  declarations  table  produced  in  the  previous 
phase,  and  produces  as  output  a complete  PL/1  program  ready  for 
compilation. 

4.5.1  Generation  of  PL/1  Program 

The  control  program  for  generating  the  complete  PL/1  program 
(CODEGEN),  as  shown  in  Figure  4.18,  accepts  the  table  of  declarations 
and  the  flowchart  table  created  during  the  previous  phase  as  input. 
The  various  types  of  entries  of  the  flowchart  table  were  described 
fully  in  Section  4.4.  They  are  the  entries  of  type  ASSN,  RFCO,  RPTN, 
FLDI , INTI,  GOTO,  MODL , LAP,  END,  DO,  PSET,  and  COND  as  described  in 
Section  4.4.  This  phase  produces,  as  output,  the  complete  PL/i  program 
and  a code-generation  report.  The  files  to  which  code  is  written  are 


described  below 
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PL/1  was  chosen  as  the  object  language  because  of  Its 
versatility,  ease  and  richness  in  data  structures,  control  structures, 
and  other  language  features  suitable  to  business  data  processing 
programs,  and  its  growing  acceptability  in  this  realm.  Nothing  in  the 
Processor  up  to  this  point,  however,  depends  on  the  object  language 
being  PL/1,  and  this  in  fact  was  a major  reason  for  the  modularity. 
Therefore,  generating  a program  in  another  object  language,  such  as 
COBOL,  would  be  a straight-forward  though  tedious  conversion  of  the 
following  code-generation  procedures. 

Generating  the  PL/1  program  code,  as  can  be  seen  in  Figure  4.19, 
is  accomplished  by  processing  the  input  cables  described  above  and 
invoking  the  appropriate  code-generation  sub-routine.  Algorithm  GENPL1 
shows  the  Generate  PL/1  Progran  Control  procedure.  The  executable  PL/1 
code  is  generated  by  inputting  the  flowchart  table  entries  one  at  a 
time,  and  invoking  the  code-generation  routine  that  corresponds  to  the 
type  of  operation  (Steps  2-3).  The  tests  for  each  type  of  code  to  be 
generated  are  in  decreasing  order  of  frequency.  These  include  code- 
generation routines  for  input-output  operations,  for  invoking  and 
writing  of  object  sub-procedures,  for  assigning  implicit  values  to 
fields,  and  for  generating  control  structures. 

The  executable  PL/1  code  is  written  out  to  the  "PL1EX"  file, 
while  associated  PL/1  "ON"  conditions  are  written  to  the  "PL10H"  file. 
The  PL/1  procedures  (which  contain  asssertions  plus  functions)  are 
written  to  the  PL1PR0C  file.  The  PL/1  code  for  declaring  the  object 
data  items  is  written  to  a "PL1DCL"  file. 
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Algorithm  CENPL1:  Generate  PL/1  Program  Control  Procedure 


[Subroutines  called:  GPROCCD,  GENIOCD,  GIMFLD,  GENGOTO,  CMODCD, 

GENLAB,  CENEND,  GENDO,  CENRSET,  GENCOND] 


Step  1.  Read  next  flowchart  table  entry;  if  end-of-file,  then  go  to 
Step  A. 

Step  2.  Branch  on  flowchart  entry  type  and  call  appropriate  routine  as 
follows : 

If  ASSN,  then  Call  GPROCCD. 

If  RECD  or  RPTN,  then  call  GENIOCD. 

If  FLDI  or  INTI,  then  call  GIMFLD. 

If  COTO,  then  call  GENCOTO. 

If  MODL,  then  call  CMODCD. 

If  LAB,  then  call  GENLAB. 

If  END,  then  call  GF.NFND. 

If  DO,  then  call  GENDO. 

If  RSET,  then  call  CENRSET. 

If  COND,  then  call  GENCOND. 


. . 
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All  these  code-generation  sub-routines  together  with  the 
necessary  transformations  are  described  in  the  following  sub-sections. 
The  algorithms  that  are  used  in  the  following  sub-sections  are 
explained  by  referring  to  the  input  flowchart  table  entry,  the 
generated  PL/1  code,  and  the  transformations  between  them.  Tables  will 
be  used  to  show  the  code  that  is  generated  in  the  various  cases. 

A. 5. 1.1  Generating  the  Procedure  Heading  Code 

The  routine  for  generating  the  heading  of  the  PL/1  module  for 
which  code  is  being  generated  (GMODCD)  is  called  by  the  Generate  PL/1 
control  routine  after  the  flowchart  entry  for  a module  statement  is 
read.  This  routine  has  the  simple  task  of  accepting,  as  input,  the 
flowchart  table  entry  for  the  module  name  (as  was  described  in  Section 
4. 4.3.2),  and  producing,  as  output,  the  PL/1  procedure  declaration: 

H + 

I I 

iModule  name:  PROC  OPTIONS  O’AIN);  | 


as  the  first  statement  of  the  program.  This  statement,  unlike  the 
executable  statements  produced  in  this  section,  is  written  to  the 
PL1HCL  file  (rather  than  the  PL1EX  file)  in  order  that  it  appear  as 
the  first  statement  in  the  program.  (The  PL10CL  file  with  the 
declarations  yet  to  be  written  to  it,  will  precede  the  PL1EX  file  with 
executable  statements  in  the  final  program). 


2R3 


-Y95-- .nr* 


4. 5. 1.2  Generating  Input/Output  Code 

The  routine  for  generating  input/output  code  (GENIOCD)  is  invoked 
by  the  generate  PL/1  code  control  routine  after  reading  a flowchart 
entry  that  corresponds  to  an  I/O  command.  It  accepts,  as  input,  an 
entry  from  the  flowchart  table  corresponding  to  a record 
(FLOWTAB_REC ) , which  was  created  and  described  in  Section  4.4. 3. 3.  The 
entry  in  the  table  already  has  all  the  necessary  information  relevant 
to  generating  the  appropriate  PL/1  I/O  statement,  including  the  file 
organization,  input/output  direction  or  mode,  the  key  field,  etc.  This 
routine  generates  the  PL/1  READ,  WRITE,  or  REWRITE  Statements  with  the 
appropriate  parameters  based  on  the  flowchart  table  entry,  as  well  as 
any  control  code  or  condition  code  associated  with  the  input/output 
operation. 

To  summarize  the  transformations  of  Algorithm  GENIOCD  from  the 
flowchart  representation  of  the  input/output  code  to  the  corresponding 
PL/1  statements.  Table  4.9  is  given  here  instead  of  an  algorithm  form 
for  the  sake  of  clarity.  If  the  value  of  the  components  of  the 
flowchart  table  entry  are  as  indicated  in  the  first  four  columns  of 
Table  4.9,  then  the  code  generated  is  indicated  in  the  last  two 
columns.  The  upper  case  letters  represent  part  of  the  actual  PL/1 
string  being  generated,  whereas  the  lower  case  letters  are  the  meta- 
names of  the  items  obtained  from  the  flowchart  table  during  program 


generation. 


Ii/O 
| MODE 

I 

■) 

|RD 

I 


ORG 


-) 

|RD 

I 

I 

I 


KEYED 


KEY 

NAME 


GENERATED  PL/1  I/O 
STMT  WITH  ASSOCIATED 
CONTROL  CODE 

READ  FILE ( filenames) 
INTO(  recname-S ) ; 


OTHER  PL  1 CODE 
GENERATED 


ON  ENDFILE 
(filenames ) 
GOTO  SFINISH ; 


yes 


I 

-| 

|RD 

I 


$RD-filenameS: 

READ  FILE  (filenames) 
INTO  (recnameS); 

DO  WHILE 

(k<  POINTER.  Recname); 
WRITE  FILE  (filenameT) 
FROM  (recname-S); 

READ  FILE  (filenames) 
INTO  (recnameS); 

END; 

IF  k>  POINTER.  Recname 
THEN  CALL  SNOTFOUND 
(filenames) ; 


ON  ENDFILE 
(filenames ) 
CALL  SNOTFOUND 
('filename's ) ; 


— (■ 


yes 


READ  FILE  (filenames) 
(filenames ) 

INTO  (recname-s) 

KEY  (POINTER.  Recname) 


OH  KEY 

CALL  SNOTFOUND 
(' f ilenameS ' ) 


-J 

|WR 


yes 
or  no 


WRITE  FILE  ( filenameT) 
FROM  (recname-S); 


H — 

|RW 


yes 


REWRITE  FILE 
(filenameT) 

FROM  ( recname-S ) 

KEY (POINTER.  Recname); 


Table  4.9 


Input/Output  Transformations  from  Flowchart  Table  to  PL/1 
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For  exanple,  the  "READ"  flowchart  table  record  generated  for 
SALEP.EC  of  the  DEPSALE  problem,  was  shown  in  Section  4.4.3.  3.  Such  an 
entry  describes  a READ  statement  from  a sequential  non-keyed  file,  and 
this  routine  would  generate  the  following  PL/1  code: 

READ  FILE  (TRANS ) INTO  (SALERFC_S  ) ; 

Notice  the  use  of  the  special  POINTER  names  in  the  cases  of  keyed 
files.  Their  evaluation  will  have  automatically  been  previously 
executed  by  virtue  of  their  precedence;  i.e.  the  POINTER  name  is 
precedent  to  the  record  name. 

The  second  case  in  this  chart  is  more  complex  because  it  involves 
searching  the  sequential  file  for  a '-ecord  whose  key  field  is  the 
desired  one  to  which  there  is  a pointer.  Since  the  file  is  sequential, 
searching  for  the  record  involves  successive  READS  in  a loop.  The 
WRITE  statement  in  this  loop  is  generated  only  in  the  case  that  the 
sequential  file  is  to  be  updated  (both  input  and  output).  There  are 
other  functionally  equivalent  ways  to  write  PL/1  code,  but  these  were 
chosen  for  ease  of  implementation,  style,  or  efficiency. 

4. 5. 1.3  Generating  Code  for  Variable  Length,  Optional,  and  Variably 
Repeating  Data 

When  all  the  fields  of  a record  are  of  a fixed  length  and  occur  a 
fixed  number  of  times  the  read  (or  write)  statements  that  are 
generated  as  shown  above  are  sufficient  to  cause  the  data  in  the 
record  to  be  transferred  to  (or  from)  the  PL/1  hierarchic  data 
structure.  However,  the  MODEL  language  as  previously  indicated,  has 
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facilities  to  describe  variable-length  fields  or  variably-existing 
groups  or  fields,  where  length,  existence,  or  repetition  is  to  be 
determined  dynamically  by  evaluating  user-provided  assertions.  The 
difference  between  such  general  facilities  of  MODEL  for  variability 
and  the  less  general  ones  in  PL/1  (the  PL/1  REFER  option  and  variable- 
length  strings  in  PL/1)  have  already  been  described  in  Section 
4.  4.  T.4.  Therefore,  generation  of  input/output  code  for  records  with 
such  items  cannot  simply  transfer  the  data  directly  in  and  out  of  the 
PL/1  data  structure.  Instead,  the  PL/1  code  to  be  generated  here  must 
simulate  the  variability  provided  in  MODEL.  As  explained  in  the 
corresponding  section  within  flowchart  generation  in  Section  4.4. 3. 4, 
the  information  necessary  for  such  data  "packing"  and  "unpacking" 
operations  has  already  been  identified  in  the  flowchart  entry 
(i.e.  the  group  and  fields  that  have  such  variable  length  or 
repetition  are  indicated). 

Algorithms  "Generate  Packing"  and  "Generate  Unpacking"  show  the 
generation  of  code  for  variable  length,  optional,  and  variably 
repeating  data  by  generation  of  "unpacking'  operations  following  the 
READ  and  generating  "packing"  operations  before  the  WRITE.  The  data 
structures  and  strategy  that  are  used  in  the  generated  program  are  as 
follows:  for  each  file  there  are  two  buffers  — one  which  is  just  a 
PL/1  string  for  each  record  of  the  file  and  the  other  buffer  is  the 
PL/1  hierarchic  data  structure.  The  process  of  "unpacking"  is  the 
scanning  of  the  string  buffer  and  copying  of  the  exact  data  amount  to 
the  hierarchic  data  structure,  while  the  process  "packing"  is  in  the 
reverse  direction. 
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Algorithm  Generate  Unpacking 

(generation  of  code  for  input  variable-length,  optional,  and  variably- 
repeating  data  by  "unpacking") 

Names  and  Da ta  Structures  used  by  this  algorithm; 

Flowchart  Table  Entry  for  variable  length  records  — already  described 
in  Section  4. A. 3. A.  Its  components  are  NAME,  TYPE,  ^SUBSCRIPTS,  SUB1, 
SUB 2,  EXIST-PROC,  ARITY,  FIELD-TYPE,  FIELD-LFN-TYPE,  MIN-LENCTH,  MAX- 
LENGTH,  LEH-PROC. 

RECSTRING:  string  buffer  for  record 

RF.CNAME. NAME:  a field  or  group  name  in  hierarchic  data  structure  of 

record  called  recname. 

NSTR:  level  number  in  hierarchical  tree. 

SUB  SCRIPT -STACK:  Stack  of  PL/1  index  names  to  repeating  fields  and 
groups;  has  the  form  "Inn"  where  "nn"  is  the  level  in  the  tree. 

Sub-structure:  name  used  to  refer  to  a sub-tree  in  the  hierarchical 
data  structure. 

Step  1.  Initialize  subscript  stack. 

Step  2.  Set  NSTP»0  (substructure  number). 

Step  3.  Generate  'I*>1'  to  initialize  buffer  pointer  in  object  program. 

Step  A.  Call  UNPACK(l)  for  each  top-level  member  of  the  record 
(parameter  is  next  index  to  use  as  subscript  or  do-variable). 

Step  5.  Return. 


Algorithm  Generate  Packing 

(generation  of  code  for  output  variable-length,  optional,  and 
variably-repeating  data  by  "packing"). 

Step  1.  Initialize  subscript  stack. 

Step  2.  Set  MSTR-0  (substructure  number). 

Step  3.  Generate  "record-string  ■ ""  in  order  to  initialize  output 
buffer. 

Step  A.  Call  PACK(l)  for  each  top-level  member  of  the  record 
(parameter  is  next  index  to  use  as  subscript  or  do-variable). 

Step  5.  Return. 


^ t ■*&■**& ..  rsj 
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PL/l  code  is  generated  here  for  dynamic  computation  of  length, 
existence,  or  repetition.  After  a READ  statement  is  generated  for  a 
record  with  any  of  the  above  variability,  code  is  generated  to 
"unpack"  the  data  by  calling  "Generate  Unpacking"  and  its  subroutines. 
Code  is  generated  to  scan  the  input  buffer  from  left  to  right  on  a 
field-by-field  basis.  If  a field  indicated  in  the  flowchart  table 
entry  has  variable  length,  a CALL  is  generated  to  the  assertion  which 
determines  its  length;  i.e.  the  assertion  whose  target  is  LEN.X,  where 
X is  the  name  of  the  field.  Thus,  the  length  of  the  field  is  known, 
and  further  code  is  generated  to  transfer  the  data  in  the  buffer  to 
the  corresponding  field  name  in  the  PL/l  hierarchic  data  structure. 
Likewise,  if  a field  or  group  is  indicated  to  repeat  a variable  number 
of  tines,  code  is  generated  to  CALL  the  assertion  that  determines  the 
number  of  repetitions;  i.e.  to  the  assertion  whose  target  is  EXIST. X 
wtiere  X is  the  name  of  the  variably-repeating  group  or  field.  A 
"subscript  stack"  (a  stack  of  the  form  101,  102,  etc.)  is  maintained 
in  case  repeating  groups  or  fields  are  nested.  These  indices  are  used 
for  subscripting  and  for  PL/l  "DO-loop"  variables.  Further  code  is 
generated  to  move  the  exact  number  of  repetitions  of  the  item  in  the 
buffer  to  the  corresponding  name  in  the  PL/l  hierarchic  data 
structure.  In  all  these  cases,  the  PL/l  data  names  allow  for  the 
maximum  amount  of  length  or  repetition. 


Subroutine:  (UN )PACK  (next-index) 

(a  recursive  procedure  which  supervises  generation  of  code  for 
(un)packing  records  before  they  are  read/written). 

Parameter  "next-index"  is  next  index  to  use  in  a do-loop  or  for 
subscripting. 

Step  1.  Set  NSTR-NSTR+1  (next  sub-structure). 

Step  2.  If  member  type  is  'F'  (field),  then  go  to  Step  3. 

If  member  type  is  'G ' (group),  then  go  to  Step  9. 

Step  3.  (UN)PACKFLD  — Steps  3 through  7: 

Branch  on  case: 

Step  4.  Case  1:  ^SUBSCRIPTS-!)  (field  occurs  only  once) 

If  packing,  then  Call  GEN-MOVE-INSTR -FOR -PACKING  ; 
if  unpacking, then  Call  CEN-MOVE-INSTR -FOR -UNPACKING. 

Co  to  Step  8. 

Step  5.  Case  2:  0SUBSCRIPTS-1  (field  occurs  a fixed  number  of  times) 
Push  subscript  on  to  stack. 

Generate  'DO  Inn-1  TO  subscript  1'. 

if  packing,  then  Call  GEN-MOVE -INSTR -FOR -PACKING  ; 

if  unpacking,  then  Call  GEN-MOVE -INSTR -FOR-UNPACKING. 

Generate  'END'  (end  of  loop). 

Pop  subscript  from  stack. 

Go  to  Step  8.  x 

Step  6.  Case  3:  //SUBSCRIPTS-2  & SUB  SCRIPT  2-1  (optional  field): 

Cenerate  'CALL  exist-procedure' . 

Generate  'DO  Inn  - 1 TO  EXIST.  Name'. 

if  packing,  then  Call  GEN-MOVE -INSTR -FOR -PACKINC ; 

if  unpacking,  then  Call  GEN-MOVE -INSTR -FOR-UNPACKINC. 

Generate  'END' 

Co  to  Step  8. 

Step  7.  Case  4:  (/SUBSCRIPTS-2  & SUBSCRIPT2>1  (field  repeats  a variable 
number  of  times) 

Push  subscript  on  to  stack. 

Generate  'CALL  exist-procedure'. 

Cenerate  'DO  Inn  - 1 TO  EXIST.  Name'. 

if  packing,  then  Call  GEN -MOVE -INSTR -FOR -PACKING ; 

if  unpacking,  then  Call  CEN-MOVE-INSTR -FOR -UNPACKING. 

Generate  'END' 

Pop  subscript  from  stack. 


Step  8.  Return 


Subroutine  (UN )PACK  (continued) 


Step  9.  (UN)PACKCRP  steps  9 through  13: 

Branch  on  case: 

Step  10.  Case  1:  #SUBSCRIPTS-0  (group  occurs  only  once) 

Call  (UN)PACK  (next_index)  recursively  for  each  member  of  the 
group. 

Return. 

Step  11.  Case  2:  #SUBSCRIPTS-1  (group  repeats  a fixed  number  of  times) 

Push  subscript  on  to  stack. 

Generate  '00  Inn-1  TO  subscript  1'. 

Call  (UN)PACK  (next_index  + 1)  recursively  for  each  member  of  the 
group. 

Generate  'END' 

Pop  subscript  from  stack. 

Return. 

Case  3:  //SUB  SCRIPTS -2  & SUBSCRIPT 2-1  (optional  group): 

Generate  'CALL  exist_procedure' . 

Generate  'DO  Inn  - 1 TO  EXIST.  Name' 

Call  (UN)PACK  (next_index+l ) recursively  for  each  member  of  the 
group. 

Generate  'END' 

Return. 

Case  A.  #SUBSCRIPTS-2  & SUBSCRIPT2>1  (group  repeats  a variable  number 
of  times) 

Push  subscript  on  to  stack. 

Generate  'CALL  exist_procedure' . 

Generate  'DO  Inn  - 1 TO  EXIST.  Name' . 

Call  (UN)PACK  (next_index  +1)  recursively  for  each  member  of  this 
group. 

Generate  'END' 

Pop  a subscript  from  the  stack. 

Re  turn. 


Optionality  Is  effected  whenever  the  Item  is  defined  to  repeat 
zero  or  more  times.  The  above  procedure  handles  optionality  as  well 
because  the  EXIST  variable  would  return  zero,  and  no  repetitions  for 
the  item  would  be  moved  or  used. 

Similar  code  is  generated  when  the  variable  items  are  in  an 
output  record,  except  that  the  code  is  generated  to  "pack"  the  data 
from  the  PL/1  data  names  to  the  output  buffer.  The  "Cenerate  Packing" 
procedure  of  the  above  Algorithm  is  called  before  each  WRITE  of  a 
record  with  variable  repetition,  existence,  or  length.  For  variable- 
length  fields,  code  is  generated  to  call  the  length-evaluating 
procedure  and  then  to  move  the  exact  length  of  the  field  to  the  output 
buffer.  Similarly,  for  variable-repetition,  code  is  generated  to  CALL 
the  procedure  determining  the  number  of  repetitions  and  then  to  move 
the  exact  number  to  the  output  buffer. 

In  all  these  algorithms,  generated  code  is  between  the  quotes. 
Upper  case  within  quotes  represents  object  names  in  the  generated 
code,  whereas  lower  case  between  the  quotes  represents  names  to  be 
generated  by  the  Processor.  Upper  case  elsewhere  represents  meta-names 
or  procedures  in  the  Processor. 

The  code  that  is  generated  here  is  made  clearer  by  the  following 
example.  Consider  the  following  sample  MODEL  statements  for  a record  R 
of  a source  sequential  file  F: 
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Subroutine  GEM-MOVE -INSTR-FOR -UNPACKING 

Step  1.  If  FIELD-TYPE-'C ' or  'N'  (character  or  numeric  character)  and 
if  FI ELD_LEN_TYPE»F  (fixed  length)  then  go  to  Step  5. 

Step  2.  If  FIELD_TYPE-'C ' or  'N'  and  FIELD_LEN_TYPE«'V ' (variable 
length)  then  go  to  Step  6. 

Step  3.  If  FIELD_TYPE-'B ' (binary)  then  go  to  Step  7. 

Step  A.  If  FTELD_TYPE-'F ' (fixed  decimal)  then  go  to  Step  8. 

Step  5.  (character  or  numeric  fixed-length  field): 

Generate  ' recname.name( . . . )»  SUBSTR  (recstring,I,min-length) ' 
Generate  'I-I+min-length' 

Return. 

Step  6.  (variable-length  character  or  numeric  field): 

Generate  'CALL  len-procedure' 

Generate  ' recname.namc( . . . )»  SUBSTR 
(recstring,I,LF.N.name) ' 

Generate  'I «I+LEN.name' 

Return. 

Step  7.  (field  is  binary)  If  min-length  (nunber  of  bits)  < 16  then 
//bytes-2;  else  tfbytes-A;  go  to  Step  9. 

Step  8.  (fixed  decimal)  Set  tfbytes-ceil  (.  5*(nin-length+l  ) ) 

Step  9.  Generate  'UNSPEC  ( recname. name( ...) )-  UNSPEG (SUBSTR 

(recstring,  I,  kbytes)) 

Generate  'I-I+fPbytes' 

Step  11.  Return. 

Subroutine  GEN-MOVE -INSTR-FOR -PACKING 

Step  1.  If  field  type  is  'C'  or  'N'  then  go  to  Step  3. 

Step  2.  If  field  type  is  'B'  or  'F'  then  go  to  Step  5. 

Step  3.  Generate  ' recstring-recst ring | | recname. name  (...) ' 

Step  A.  Return. 

Step  5.  Generate  'UNSPEC  (recstring)-  UNSPEC  (recstring)  | | UNSPEC 
(recname. name (...)) 

Step  6.  Return. 

(note:  in  all  above  cases,  '...'  is  the  nested  subscripts  from  the 
subscript  stack) 


t •»*;«**.  * 
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R IS  REC0RD(A,B,C(1: 10)); 

A IS  FIELD (CHAR  (5)); 

B IS  FIELD(CHAR(I: 20)); 

C IS  CR0UP(C1,C2); 

Cl  IS  FIELD (CHAR (2)); 

C2  IS  FIELD (CHAR  (3)); 

• • • 

C_ASSN:  ...  EXIST. C - . .. 

R_ASSH:  ...  LEN.B  «... 

Then  the  following  code  Is  generated  here: 
READ  FILE (F)  INTO(R_S); 

R. A-SUBSTR (R_S ,1,5); 

I-I+5; 

CALL  R_ASSN; 

R. B-SUB  STR (R_S , I , LEN.  B) ; 

I-I4LEN.B; 

CALL  C_ASSN ; 

DO  101-1  TO  EXIST. C; 

R.C1-SUBSTR(R_S,I, 2); 

I-I+2; 

R.C2-SUBSTR (R_S,I, 3); 

I-I+3; 


F.ND ; 
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4. 5. 1.4  Generating  Procedures  Code 


The  "Generate  Procedures  Code"  (CPROCCH)  routine  is  invoked  by 
the  "Generate  PL/1  Code"  control  routine  after  reading  a flowchart 
table  entry  that  corresponds  to  an  assertion.  As  input  it  accepts  an 
entry  from  the  flowchart  table  corresponding  to  an  assertion,  whose 
format  was  described  in  the  "Identify  Assertions  Information"  (Section 
4. 4. 3.5).  As  output  it  produces  the  PL/1  code  which  embodies  the 
assertion,  a PL/1  CALL  to  the  procedure,  and  any  necessary  control 
code  to  govern  the  execution  of  the  procedure  invocation. 

Algorithm  (GPROCCD)  generates  the  code  presented  below.  It  also 
generates  the  conditional  code  and  replacement  code  described  in  the 
next  few  sub-sections.  The  user-provided  assertions  are  implemented  as 
PL/1  procedures  in  order  to  achieve  a top-down  and  modular  structure. 
For  each  assertion  flowchart  table  entry,  this  routine  generates  the 
following  PL/1  procedure  code  which  it  outputs  to  a PL/1  procedures 
file  (PL1PR0C): 


lAssertion:  PFOC;  I 

I I 

| assertion  text  | 

I I 

I RETURN;  | 

I I 

I END;  | 

I I 

4^— ———————————————— — — — — — — — 

where  "assertion"  is  the  name  of  the  assertion  as  originally  provided 
by  the  user,  and  "assertion  text"  is  the  text  of  the  procedure  from 
the  flowchart  table  entry.  Furthermore,  in  order  to  invoke  the 
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Algorithm  GPKOCCD:  Generated  Procedure  Code 


(Input  to  this  algorithm  is  the  flowchart  table  entry  for  assertions 
(with  components  ASSN-NAME,  FGN,  RPLAB,  TEXT)  that  was  created  and 
described  in  Section  4,4. 3. 5) 

Step  1.  Generate  code  to  call  procedure:  "CALL  Assn-name"  (sent  to 
file  PL1EX) 

Step  2.  If  RPLAR  not"'  ' (assertion  uses  REPLACE  function)  then 
generate  code  for  replacement  (see  box  of  code  in  Section  4.5. 1.7, 
sent  to  file  PL1EX) 

Step  3.  If  FCN  not"'  ' (assertion  uses  a conditional  function)  then 
generate  code  for  testing  the  function's  completion  (see  first  box  of 
code  in  Section  4.5. 1.5,  sent  to  file  PL1EX) 

Step  4.  Cenerate  body  of  assertion  (see  first  box  of  code  in  Section 
4. 5. 1.4,  sent  to  PL1PR0C  file) 


Step  5.  Return 
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generated  sub-procedure,  the  following  code  is  generated  in  the  PL1FX 
output  file  which  contains  the  main  procedure  of  the  executable 
generated  PL/1  statement: 


|CALL  assertion;  1 

I I 

^ + 

where  "assertion"  is  the  name  of  the  generated  procedure  as  was  given 
by  the  user. 

In  addition  to  the  generation  of  the  procedure  and  its 
invocation,  there  is  a possibility  that  PL/1  control  code  is  necessary 
in  cases  of  conditionality,  repetition,  and  replacements,  subjects 
which  are  covered  below. 

4. 5. 1.5  Generating  Conditional  Code 

If  the  current  flowchart  table  entry  (of  type  "assn")  has  the 
conditional  flag  up,  it  indicates  that  the  assertion  involves  the  use 
of  a system-provided  function,  whose  completion  is  conditional,  as 
explained  in  Section  4.4. 3. 5.  In  such  a case,  code  has  to  be  generated 
here  to  flag  the  completion  of  the  node  when  the  function  finishes, 
which  in  turn  triggers  execution  of  any  operations  that  depend  on  the 
completion  of  the  function.  This  code  is  generated  as  part  of  the 
CPP.OCCP  algorithm  which  already  has  been  shown  in  Section  4.5.  1.4.  In 
these  cases,  conditional  PL/1  code  has  to  be  generated  in  the  form: 


where  "function-name"  Is  the  narte  of  the  system-provided  function  and 
"f unction-name_COMPLETED"  is  the  flag  that  is  set  by  the  conditional 
function  upon  its  completion.  Asser tion_COMPLETED  is  set  to  '1'  when 
the  function  completes  its  operation  in  order  to  trigger  the  execution 
of  all  nodes  dependent  on  the  completion  of  this  node.  To  carry  this 
out,  conditional  code  before  each  dependent  node  is  generated  in  the 
form: 


|IF  assertion  COMPLETED  THEN... 


This  is  generated  by  virtue  of  the  previous  creation  of  a flowchart 
entry  for  conditionals  (refer  back  to  Section  A. 4. 3. 5 for  generation 
of  these  flowchart  table  entries). 


For  example,  i f an  assertion  called  "SUMX"  were 


|Y -SUMMAT (X .... ) 


then  the  corresponding  flowchart  entry  input  to  this  routine  would  be 


* r 
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Assn  Name 
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SUM MAT 
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Text 
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(X...) 


In  such  a case,  this  "Generate  Procedure  Code"  routine  would  not  only 
generate  the  PL/1  and  its  CALL  statement,  but  also  the  control  code  to 
test  for  the  function's  completion  and  set  the  trigger  variable  to 
indicate  the  node's  completion: 

H + 

I 

| IF  SUMMATjCOMPLF.TF.D  THFN  DO; 

I 

|SUMMAT__COMPLETED='0  'P ; 

I 

|SUMX_COMPLETED»'l ';  END; 


Furthermore,  the  conditional  flowchart  table  entry  then  causes 
generation  of  code  to  test  the  trigger  variable  before  each  dependent 
node  (the  determination  of  dependent  nodes  was  explained  in  Section 
4. 4.3. 5).  In  the  above  example,  where  the  assertion  name  is  SUMX,  the 
following  would  be  generated  before  dependent  nodes: 


-+ 

I 


| IF  SUMX  COMPLETED  THEN 


* * 
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In  summary,  the  assertions  are  implemented  as  CALLS  to  PL/1 
procedures  with  conditional  control  code  being  generated  for  testing 
conpetion  of  any  system-provided  functions  that  are  conditional,  when 
appropriate. 

4. 5.1.6  Generating  Iterative  Code 

Whenever  the  current  flowchart  entry  indicates  that  an  iteration 
begins  at  the  current  node,  PL/1  code  is  generated  by  the  GFNDO 
procedure  to  loop  through  each  of  the  elements  of  the  repeatedly 
occurring  item.  The  scope  of  the  iteration  has  already  been  determined 
in  the  scope  and  iteration  analysis  section,  and  "DO"  and  "END"  type 
flowchart  entries  have  already  been  created  during  flowchart 
generation  at  the  point  of  the  beginning  and  end,  respectively,  of 
each  loop.  The  iterative  code  can  be  implemented  by  the  PL/1  DO 
iterative  statement  generated  by  this  routine  as  follows: 

— ————————— — — — + 

I I 

|D0  FORFACH_i  - 1 to  n;  | 

I I 

"♦ — f 

where  i is  the  name  of  the  repeating  group  of  the  iteration  and  n is 
the  number  of  elements  in  the  repeating  group,  which  is  either  a 
constant  for  fixed-occurring  items,  or  "EXIST. x"  for  variably- 
occurring  items.  The  latter  is  the  value  telling  the  number  of  members 
actually  existing  in  item  x,  provided  in  another  assertion. 


300 


4. 5. 1.7  Generating  Replacement-StackinR  Code 

It  was  mentioned  earlier  that  MODEL  allows  a specification  of 
assertions  to  be  restated  with  a replacement  of  one  of  its  components 
by  one  or  more  of  a list  of  alternatives.  For  example,  in  the  DEPSALE 
problem,  if  a certain  item  was  out-of-stock,  then  there  is  an  attempt 
to  fill  the  order  by  the  first  available  of  a list  of  substitute 
items.  For  this  purpose,  a system-provided  "Replacement"  function  was 
Introduced  which  had  the  form 
Y-REPLACE(X) 

The  procedure  resulting  from  this  statement  was  that  the  list  in  X, 
was  to  be  stacked  and  delivered  one  at  a time  to  Y,  with  all 
assertions  dependent  on  Y to  be  repeated  until  another  route  was  taken 
(such  as  the  completion  of  the  order  in  the  DEPSALE  problem)  or  until 
the  ll^t  of  substitutions  was  exhausted  or  emptied. 

The  implementation  of  such  a feature  can  best  be  implemented  as  a 
system-provided  run-time  function  called  "REPLACE".  tJhen  this  function 
is  invoked  as  Y=REPLACE(X),  it  would  have  the  following  steps: 

W 

(1)  the  first  time  that  it  is  invoked  (indicated  by  a flag 
called  ALRRFPL)  , a stack  is  created  with  all  the  X's. 

(2)  The  top  element  of  X is  delivered  to  Y. 

(3)  If  the  stack  is  empty,  then  the  EMPTY  choice  is  taken.  If 
none  is  provided  by  the  user,  then  the  system  defaults  to 
printing  a standard  message  and  a branch  is  made  to  process 
the  next  record. 


- ; m 


X t 
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Code  for  the  REPLACE  function,  as  well  as  for  other  system- 
provided  functions,  can  he  found  in  Appendix  R along  with  code  for  the 
systen  nodules  in  alphabetical  order. 

When  the  replacement  takes  place  by  virtue  of  such  a CALL,  code 

needs  to  be  generated  to  branch  to  the  first  dependent  node  on  Y as 

determined  during  flowchart  generation.  This  code  is  generated  as  part 
of  the  CFROCCD  algorithm  which  has  already  been  shown  in  Section 

4. 5. 1.4.  The  following  PL/1  code  is  generated  immediately  after  the 
CALL  to  the  replacement: 

i + 

I I 

| I F WASREPL  THEN  | 

I I 

| I F ~ CHOICE. EMPTY  THEN  00;  WASREPL-'O'R ; | 

I I 

|G0  TO  n;  | 

I I 

IEND;  ! 

I I 

H + 

where  n is  the  label  corresponding  to  the  first  node  dependent  on  Y. 

This  code  can  be  interpreted  as:  if  a replacement  took  place  (the 

WASREPL  flag  is  set  by  REPLACE  to  indicate  that  a replacement  was 
done),  and  if  there  was  a replacement  left  (CHOICE  is  not  empty),  then 
reset  flag  and  go  to  try  another  loop  with  the  replacement.  In  the 
DF.PSALE  problem,  for  example,  when  a substitute  item  is  used,  a branch 
is  needed  back  to  the  point  where  the  item  ordered  is  processed. 


i 
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Furthermore,  code  needs  to  be  generated  to  empty  the  stack  of 
replacements  whenever  the  next  replacement  results  in  a choice  other 
than  another  replacement.  This  is  accomplished  by  resetting  the  flaps 
shown  above  as  follows: 

WASREPL-0 

ALRREPL-0 

//STACKS 

The  (KSTACK  variable  is  the  level  in  the  STACK  used  by  the  REPLACE 

function  (the  STACK  is  implemented  as  an  array).  Resetting  the  /tSTACK 

index  effectively  empties  the  stack  by  making  it  available  for  reuse 
(see  Section  4.5.  1.9  on  resetting  variables).  In  cases  where  the 
REPLACE  feature  is  used  in  multiple  assertions,  different  stacks  need 
to  be  generated  each  with  a unique  name,  although  this  was  not 
demonstrated  here. 

4. 5.  1.8  Generating  Code  for  Implicit  Field  Assignments 

Hie  "Generate  Code  for  Implicit  Field  Assignments"  (GIMFLD) 

routine  is  invoked  by  the  Generate  PL/1  Code  control  routine  when 
reading  a flowchart  table  entry  for  implicit  field  associations. 
Recall  that  such  a node  in  the  flowchart  tahle  was  created  for 
implicit  correspondence  of  fields  in  the  absence  of  explicit 

assertions,  using  such  associations  as  same-named  items,  "OLD"  and 
"NEW"  keywords,  etc.  Algorithm  GIMFLD  simply  generates  the 
corresponding  PL/1  code  show  below,  and  therefore  it  is  omitted. 


: 

y 


iTarget  field  “ implicit  source  field; 


with*  these  two  items  designated  already  in  the  flowchart  table  entry. 


A. 5. 1.9  Generating  Code  for  Resetting  Switches  and  Flags 


Upon  reaching  a "reset"  type  flowchart  entry  (as  described  in 
Section  4.4.3. 9),  code  is  generated  to  reset  the  indicated  variable  to 
zero  as  follows: 


where  X is  the  variable  to  be  reset.  Recall  that  all  choices, 
conditions,  and  replacement  flags  are  reset  at  the  end  of  the 
outermost  loop  before  going  back  to  read  the  next  record.  Variables 
associated  with  specific  functions  (such  as  totals),  however,  are  not 
reset  here,  but  rather  by  the  function  itself  upon  completion. 


4.5.1.10  Generating  Code  for  Subsets 


Code  needs  to  be  generated  for  every  SUBSET  type  assertions  so 
that  only  records  meeting  the  subset  criterion  are  considered.  If  a 
SUBSET  is  given  for  a source  file,  then  code  needs  to  be  generated  to 
branch  to  read  the  next  record  if  the  subset  condition  is  not  met.  If 
a SUBSET  is  given  for  a target  file,  then  code  needs  to  be  written  to 
circumvent  the  corresponding  "write"  statements  if  the  condition  is 
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not  met.  The  code  is  generated  for  SUBSET  type  assertions  by  virtue  of 
certain  entries  already  present  in  the  flowchart  table. 

Recall  from  Algorithm  IDASSN,  Step  7 (Section  4. 4. 3. 5)  that  if  a 
SUBSET  assertion  was  given  for  a source  file  (i.e.  the  assertion  had  a 
target  of  the  form  "SUBSET.  Filename",  where  "filename"  is  the  name  of 
a source  file),  then  flowchart  table  entries  of  types  CONO  and  GOTO 
were  written  after  the  entry  for  the  source  record.  The  code  that  is 
generated  for  the  condtional  test  is  the  following: 

IF  “SUBSET.  Filename  THEN  GO  TO  r; 
where  r is  the  label  of  the  READ  for  the  next  record. 

For  SUBSET  assertions  for  target  files.  Algorithm  IDI000  Step  10 
(Section  4.4.3. 3)  generated  a CONO  type  flowchart  table  entry  prior  to 
the  flowchart  entry  for  the  record  in  order  to  test  for  the  subset 
criterion  before  writing  the  record.  Whenever  a SUBSET  is  described 
for  a target  file,  the  following  code  is  always  generated  immediately 
before  the  WRITE: 

IF  “SUBSET.  Filename  THEN 

Since  this  is  generated  immediately  before  the  corresponding  WRITE, 
the  record  is  thereby  not  written  if  the  criterion  is  not  met. 
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4.5.1.11  Generating  PL/1  Declarations 

The  "Generate  PL/1  Declarations"  routine  (GPL1DCL)  has  the  task 
of  accepting  as  input,  the  Declarations  Table  as  presented  in  Section 
4.4.3.11,  and  produces,  as  output,  the  corresponding  PL/1  declarations 
which  in  turn  cause  the  PL/1  compiler  to  allocate  storage  for  the  data 
to  be  used  by  the  object  program.  Algorithm  CPLlDCL  generates  the 
declaration  code  from  the  Declaration  Table. 

Recall  from  Section  4.4.3.11  that  the  Declarations  Table  entry 
already  contains  all  the  information  necessary  in  order  to  generate 
the  PL/1  declarations  here,  including  the  name  being  declared,  the 
type  of  name,  the  "level"  within  the  object  hierarchic  data  structure, 
and  any  other  attributes  necessary  for  the  declaration. 

If  an  entry  in  the  Declarations  Table  is  for  a FILE  name,  a PL/1 
declaration  is  generated  for  the  file,  depending  on  the  file 
attributes,  according  to  the  chart  in  Table  4.10.  Notice  that  a unique 
file  name  is  needed  and  generated  by  suffixing  the  letter  'S',  'T',  OR 
'U'  to  the  user-provided  file  name,  depending  on  the  direction  of  the 
information  flow  (source,  target,  or  both).  The  rationale  for  this 
suffix  has  been  explained  in  Sections  4.4.3. 3 and  4.4.3.11.  The  PL/1 
compiler  uses  the  file  declarations  for  building  internal  file  control 
tables  and  for  communicating  with  the  operating  system. 
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Algorithm  CPL1DCL:  Generate  PL/1  Declarations 


(Input  Declaration  Table  as  described  in  Section  4.4. 3. 11) 


Step  1.  Read  next  declaration  entry,  at  end  go  to  Step  9. 


Step  2.  If  entry  type  - 'FL'  then  generate  file  declaration  according 
to  Table  4. 10. 


Step  3.  If  entry  type  = 'RC'  then  generate  "DGL  recname  CHAR (n) 
[VAR] 


Step  4.  If  entry  type  - 'FP'  then  generate  file  name  as  highest  level 
name  in  PL/1  hierarchical  structure  (See  Table  4.11);  if  file  is  both 
source  and  target,  generate  "OLD"  and  "NEW"  declarations  (as  in  Table 
4.  11). 


Step  5.  If  entry  type  = 'P.P'  then  generate  record  nane  as  second 

highest  entry  in  PL/1  hierarchical  structure  (See  Table  4.11) 


Step  6.  If  entry  type  = 'CP'  then  generate  "n  GRP  (m)," 


Step  7.  If  entry  type  ■ 'FD'  then  generate  "n  fieldname  fieldtype  (n) 
[var];" 


Step  8.  Co  to  Step  1. 


Step  9.  Return. 


* • H 
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If  fila  is 


■ Then  The  Declaration  is 


I 1 i • ; 

Input  ; Output  , Sequential  ; Indexed  i , 

i i i 


i I XL  X\ I 'S'FIL Z HI PIT  RECORD  SEQUENTIAL 
; DCL  X|  [ 'T'  FILE  OUTPUT  RECORD  SZQL; 

; DCL  X| | 'S'  FILE  INPUT  RECORD  SEQL; 

I , 

■ DCL  X| | 'T'  FILE  OUTPUT  RECORD  SEQL; 

i XL  X|  | 'S'  FILE  INPUT  KEYED 
I ; INDEXED  DIRECT, 

t . 

i ' XL  X|  | 'T'  FILE  OUTPUT  KEYED 
j i INDEXED  DIRECT; 


XL  X|  | 'U'  FILE  UPDATE  KEYED 
; INDEXED  DIRECT 


Table  4.10 

Generation  of  PL/1  File  Declaration 


Pt  T 'L*.  . *5 
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If  the  Declarations  Table  entry  Is  for  a RF£0RD  name,  then  a PL/1 
string  Is  declared  which  is  used  by  the  PL/1  program  as  a program  area 
buffer  for  I/O  operations.  The  PL/1  declarations  generated  here  is 

I I 

|DCL  recname  CHAR  (n)  [VAP. ) ; | 

I I 

— — — 1 — — — + 

where  the  "recname"  is  the  name  of  the  record. 

The  file  and  record  names  in  the  Declarations  Table  are  also  used 
to  generate  the  PL/1  declarations  for  the  beginning  of  the  hierarchic 
data  structure  of  the  record.  The  schema  of  the  chart  in  Table  4.11 
indicates  how  the  beginning  of  such  a PL/1  hierarchic  structure  is 
generated  according  to  the  file  attributes.  Notice  that  if  a file  is 
both  a source  and  a target  file,  both  an  "OLD"  and  "NEW"  area  is 
declared  and  allocated  memory. 

The  other  declarations  in  the  PL/1  data  structure  are  generated 
by  this  routine  upon  processing  the  Declarations  Table  entries  for 
groups  and  fields.  If  the  entry  is  for  a group,  then  a declaration  for 
the  group  name  is  simply  generated  at  the  current  level  in  the  tree 
(with  the  subordinate  fields  to  follow)  with  possible  repetition 

factor  following,  as  shown  below: 

•4 + 

I I 

In  NRP  (m),  | 

I I 

^ ——  — — — — — — — — — — — — — — f- 

where  n is  the  level  in  the  tree,  NRP  is  the  name  of  the  group,  and  m 
is  the  number  of  repetitions,  if  any. 
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If  the  Declarations  Table  entry  is  for  a field,  then  a field 
declaration  is  generated  in  PL/1  at  the  current  level,  with  all  the 
attributes  that  have  been  filled  into  the  declarations  table  entry. 
The  generated  PL/1  field  declaration  has  the  following  form: 


In  fieldname  fieldtype  (m)  [var]  ; | 

I I 

———————————————— — — — — —————————————— —— — r* 

where  n is  the  tree  level;  fieldname  is  the  name  of  the  field;  the 
field  type  is  character  (CHAR),  binary  (BIN),  numeric  (NUMERIC),  or 
fixed  decimal  (FIXED);  n is  the  length  of  the  field;  and  VAR  is  the 
optional  PL/1  attribute  to  indicate  a maximum  length  to  be  allocated 
for  a string. 

Generation  of  the  above  declarations  all  take  place  in  this 
routine  by  reading  the  Declarations  Table  entries  one  at  a time  and 
generating  the  corresponding  PL/1  declarations  code,  which  turns  out 
to  be  a fairly  straight-forward  transformation. 

4.5.1.12  Othpr  Code-Ceneration  Supporting  Routines 

Certain  routines  have  been  found  to  be  useful  to  all  the  code 
generation  routines. 

The  "L'P.ite  PL/l"  routine  (WRPL 1 ) is  called  by  each  of  the  code 
generating  routines  in  order  to  write  out  the  PL/l  code.  Two 
parameters  are  passed  to  this  routine:  the  string  of  PL/l  code  to  be 
written  and  the  output  file  to  which  it  should  be  written.  WRPL1  takes 


the  string  containing  one  or  more  generated  PL/l  statements  and  it 
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outputs  the  PL/1  statement  In  the  format  and  syntax  that  the  PL/1 
compiler  expects.  It  ensures  that  the  statement  fits  In  columns  2 to 
72  of  each  card  necessary  for  the  statement  produced  and  generates 
sequence  numbers  in  columns  73  to  80  of  each  card  Image. 

The  WPite  DeCLarations  routine  (L'P-DCL)  does  the  same  for  writing 
PL/1  declarations  and  Indents  the  declarations  according  to  the  level 
numbers  for  readability.  It  is  called  by  GPL10CL  in  order  to  write  out 
each  declaration.  It  is  passed  two  parameters:  the  string  containing 
the  declaration,  and  the  level  in  the  tree.  The  file  to  which  the 
declarations  are  written  is  PL1DCL. 

4. 5. 2 Code  Generation  Summary 

The  "Code  Generation  Summary"  routine  (CGSIIM)  has  the  task  of 
wrapping  up  the  code  generation  phase  and  writing  a report  to  the 
user. 


First,  the  different  files  with  the  generated  PL/1  program 
(PL1DCL,  PLintI,  PL1EX,  PL1PR0C)  are  merged  (by  MERGPL1)  into  one 
object  PL/1  file  (PL108J)  which  can  he  subsequently  compiled. 
Secondly,  a Code  Generation  Summary  Report  is  written  which  lists  the 
generated  PL/1  program  to  the  user,  and  prints  out  the  total  number  of 
lines  generated.  Uhile  the  PL/1  listing  would  not  be  of  much  use  to 
the  average  MODEL  user,  it  would  provide  a deeper  understanding  for 
the  more  sophisticated  user  or  system  programmer  for  insight  or 
debugging.  This  is  analogous  to  the  way  that  a PL/1  compiler  can  list 
a pseudo-assembly  language  listing  for  the  object  program  that  it 
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generates,  which  can  he  of  occasional  use  to  certain  users. 

This  routine  also  generates  a few  lines  of  statistics  about  the 
generated  program  that  might  be  useful  for  the  user,  including  the 
number  of  PL/1  statements  generated  and  the  amount  of  computer  time 
used  to  generate  the  program. 

The  result  of  this  entire  code  generation  process  is  thus  a 
complete  PL/1  program  ready  to  be  compiled  by  the  PL/1  compiler. 

4.6  Compilation  and  Execution  of  the  Generated  Program 

The  PL/1  program  produced  by  the  MODEL  Processor  is  submitted  to 
the  PL/1  Optimizing  Compiler  for  translation  into  the  host  machine 
language.  Since  the  MODEL  Processor  replaces  the  high-level  language 
programmer  (in  PL/1),  the  PL/1  Optimizing  compiler  was  the  target 
machine  kept  in  mind  during  generation  of  PL/1  code  by  the  Processor. 
This  enabled  the  Processor  to  leave  some  of  the  low-level  program- 
generation  and  optimization  tasks  to  the  eventual  recipient,  the  PL/1 
compiler.  For  example,  there  was  no  need  to  generate  OPEN  or  CLOSE 
statements  in  the  MODEL  Processor  because  the  PL/1  compiler  generates 
the  OPEN  before  the  first  I/O  operation,  and  a CLOSE  at  the  end.  There 
was  no  need  for  the  Processor  to  concern  itself  with  low-level 
optimization  problems  such  as  elimination  of  common  arithmetic  sub- 
expressions in  arithmetic  statements,  or  simplification  of  logical 
expressions,  since  such  optimization  is  performed  by  the  compiler. 
More  details  on  the  tasks,  facilities,  and  execution  logic  of  the  PL/1 
Optimizing  Compiler  can  be  found  in  appropriate  manuals  [PL175].  The 
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progran  design,  code-generation,  and  optimization  performed  by  the 
MODEL  Processor,  together  with  the  program  and  machine-code  Level 
optimization  of  the  PL/1  Optimizing,  Compiler  should  yield  an  efficient 
and  reliable  object  program  ready  to  be  executed. 

The  MODEL  Processor  and  the  PL/1  Compiler  could  be  invoked  as  a 
unit  by  the  MODEL  user  through  a catalogued  procedure.  Thus,  there 
would  never  be  a need  for  a user  to  view  this  as  a two-stage 
translation  process.  \ specification  would  be  submitted  at  one  end, 
and  a resulting  program  ready  for  execution  would  result  at  the  other 
end.  The  resulting  program  nodule  would  be  re-usable  as  long  as  there 
was  no  change  to  the  specification. 
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COMCLUS IONS 


The  preceding  chapters  have  described  a non-procedural  language, 
MODEL,  for  describing  modules  of  an  information  system  and  a processor 
for  generating  programs  automatically  from  specifications  expressed  in 
MODEL.  The  research,  system,  and  methodologies  presented  here  have 
demonstrated  the  feasibility  of  such  an  approach.  It  is  expected  that 
such  a language  and  system  could  he  an  important  step  toward  the 
automation  of  the  software  development  process  if  given  strong 
industrial  level  support,  reliability,  and  funding. 

While  some  work,  refinement,  and  extensions  are  needed  on  systems 
such  as  MODEL,  several  benefits  and  conclusions  are  already  evident 
from  this  research.  Such  a system  clearly  reduces  the  amount  of 
expertise  and  time  needed  to  generate  today's  typical  data  processing 
programs.  As  outlined  in  Chapter  3,  since  the  MODEL  language  is  non- 
procedural, it  enables  its  user  to  describe  data  and  their  inter- 
relationships by  providing  a set  of  descriptive  statements  that  can 
appear  in  arbitrary  order.  As  described  in  Chapter  4,  the  MODEL 
Processor,  unlike  conventional  compilers,  is  able  to  deduce  the 
sequence  of  events,  and  is  able  to  check  much  of  the  user's  logic  by 
analyzing  a specification  for  its  completeness  and  consistency  and  by 
providing  effective  feedback.  In  addition,  it  produces  the  desired 
program  complete  with  sequence  and  control  logic,  declarations, 
input/output  commands,  etc.,  relieving  the  user  entirely  of  such 
procedural  thinking.  The  amount  of  writing  required  of  the  user  is 
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certainly  reduced  as  the  ratio  of  number  of  statements  in  a typical 
MODEL  specification  to  the  number  of  generated  program  statements  is 
approximately  1:4.  hut  it  is  not  so  much  the  number  of  statements  that 
is  important  as  is  the  fact  that  the  non-procedural  and  very  high 
level  nature  of  MODEL  requires  less  expertise  than  would  programming. 

Comparing,  the  program  generated  by  the  Processor  with  a manually 
written  program,  the  execution  time  efficiency  is  good.  Unlike 
"generalized  packages,"  the  Processor  generates  an  ad  hoc  program  for 
a particular  problem.  Therefore,  the  PL/1  code  generated  is  peculiar 
to  a given  use  and  contains  no  unnecessary  instructions.  The  programs 
generated  by  the  Processor  appear  to  be  as  concise,  structured  and 
efficient  as  good  manually-written  ones,  though  their  structure  does 
not  necessarily  parallel  a human-written  program,  as  explained  in 
Chapter  4.  In  short,  the  MODEL  language  and  system  promise  to  produce 
fruitful  and  positive  results  if  research  on  such  a system  is 
maintained  and  expanded. 

There  are  several  directions  that  further  research  may  take  in 
the  future.  On  the  pragmatic  level,  there  are  a number  of  refinements 
that  could  be  made  to  make  the  current  version  of  MODEL  more 
attractive.  The  current  syntax  of  the  language  is  somewhat  restrictive 
partly  because  it  is  a formal  language,  and  partly  because  of  various 
restrictions  that  were  made,  such  as  the  decision  to  make  arithmetic 
and  logical  expressions  compatible  with  PL/1.  A worthwhile  endeavor 
would  then  be  to  make  a more  English-like  and  user-oriented  syntax.  In 
fact,  a still  more  ambitious  expansion  would  be  to  convert  the 
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Processor  to  one  with  an  on-line  real-time  capability.  An  interactive 
session  with  a user  at  a terminal  through  a natural  language  (using 
current  state-of-the-art  natural  language  techniques)  would  make  the 
interaction  between  the  user  and  the  system  much  more  effective.  Since 
a system  definer  using  the  version  of  MODEL  described  here  would 
typically  go  through  several  interactions  until  his  problem  is  solved, 
an  interactive  terminal  approach  would  certainly  enhance  this  process, 
and  such  a possibility  is  surely  one  to  he  investigated. 

There  are  various  other  extensions  that  could  be  made  to  MODEL, 
some  minor  and  some  major  in  scope.  The  current  version  supports  the 
sequential  and  indexed  sequential  access  methods,  so  it  would  be 
useful  to  extend  the  support  to  other  and  more  complex  data 
organizations  and  access  systems.  The  lihrary  of  functions  could  he 
enlarged  to  encompass  more  functions  that  would  be  useful  in  a typical 
data  processing  environment.  The  Processor  could  be  extended  to 
incorporate  more  elaborate  report  generation  facilities  as  found  in 
commercial  report  generators.  The  target  language  could  he 
supplemented  with  a choice  to  generate  COBOL  programs  rather  than 
PL/1.  Finally,  the  efficiency  of  some  of  the  algorithms  used  in  the 
Processor  could  he  improved.  For  example,  the  matrix  manipulation 
procedures  should  use  sparse  matrix  techniques  since  many  of  the 
entries  are  zero. 
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<)n  a more  research-oriented  and  significant  plane,  MODEL  itself 
could  be  extended  upwards  in  the  ladder  of  phases  of  the  software 
development  life  cycle.  In  other  words,  MODEL  could  be  extended  so 
that  the  user  would  not  have  to  separate  the  data  set  into  files  and 
not  have  to  describe  physical  media.  The  Processor  would  then  have  to 
be  extended  to  perform  these  decisions  automatically,  by  incorporating 
some  of  the  automatic  physical  design  techniques  reviewed  in  Chapter 
2.  Of  course,  the  most  challenging  work  still  remains  in  attempting  to 
automate  the  production  of  functional  specifications  themselves  by 
using  problem  solving  models  and  interaction  in  natural  language,  but 
such  progress  will  have  to  wait  for  future  years. 


In  summary,  the  MODEL  Language  and  Processor  have  made  one  step 
in  the  road  to  total  automation  of  the  software  development  process. 
While  much  research  in  this  field  lies  ahead,  it  is  hoped  that  this 
research  has  made  a contribution  towards  that  end  and  has  aided  the 
effective  utilization  of  manpower  and  machine. 


APPENDIX  A 


AN  EXAMPLE  OF  THE  USE  OF  MODEL 
DESCRIPTION  OF  A SALE  FUNCTION  IN  A DEPARTMENT  STORE 

The  purpose  of  this  appendix  is  to  provide  a conplete  example  of 
the  use  of  the  MODEL  language  and  Processor.  The  example  presented 
here  is  the  Department  Store  Sale  problem  (DEPSALE ) which  has  been 
referenced  throughout  the  dissertation,  and  segments  of  which  have 
been  used  as  examples  throughout  Chapters  3 and  A.  The  environment  of 
this  example  is  a department  store  with  many  departments,  a large 
number  of  charge  account  customers,  and  a diverse  stock  inventory. 
Point-of-sale  terminals,  connected  to  a network  of  computers,  are 
distributed  throughout  the  several  locations  of  the  department  store. 

The  function  that  the  analyst  wishes  to  describe  here  involves 
purchases  made  by  charge  account  customers.  It  is  desired  to  have  a 
computer  program  which  will  perform  the  charge  accounting  and  sale 
functions.  The  objective  of  the  following  example  is  to  show  how  this 
Department  Store  Sale  problem  (DEPSALE)  is  described  in  MODEL  and  to 
exemplify  how  the  MODEL  Processor  would  subsequently  process  this 
specification  and  automatically  generate  a program  to  perform  the 
function. 
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■ Figure  A1  is  an  illustration  of  the  DEPSALE  function,  as 
presented  in  Chapter  3.  It  shows  the  function  at  the  center  of  the 
figure,  with  all  the  interacting  data.  The  source  data  for  DEPSALE  are 
three  files:  the  sales  transactions  which  cone  from  a terminal 
(TRAMS),  sequentially,  one  at  a time,  and  which  contain  the 
information  provided  by  the  purchaser.  There  is  a customer  master  file 
(CMSTMAST)  which  uses  a disk  as  a storage  medium  and  where  records  of 
customers  could  be  referenced  by  providing  customer  numbers.  Finally, 
there  is  an  inventory  file  (IMVEN),  which  also  uses  disk  storage 
medium  and  where  information  on  stock  items  could  be  referenced  by 
providing  a stock  number. 

The  target  data  are  the  updated  records  in  CUSTMAST  and  INVEN 
affected  by  the  sale  transaction.  An  entry  is  also  made  in  a sales 
journal  (JOIIRN),  a sequential  output  file.  Finally,  a sales  slip 
(SALESLIP)  is  produced  on  the  terminal,  if  the  sales  transaction  has 
been  consunated,  or  alternately  an  exception  notice  (EXCEPT),  if  for 
some  reason  the  transaction  cannot  take  place. 

Chapter  3 has  already  presented  the  sections  and  components  of 
the  MODEL  language  in  detail.  To  review,  a MODEL  specification 
consists  of  three  major  parts:  the  header,  the  data  descriptions,  and 
the  statements  specific  to  the  module.  The  header  contains  information 
identifying  the  module  name,  the  source  files,  and  the  target  files. 


(sequential) 


Figure  A1 i Illustration  of  Department  Store  Sale 
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The  data  descriptions  describe  the  structure,  format,  and 
attributes  of  the  files  and  their  component  records  and  data  elements. 

This  section  is  independent  of  the  module  description  since  data  can 
be  used  by  several  nodules.  In  addition  to  description  of  the  data, 
this  section  may  also  be  used  to  provide  media  descriptions  and  a set 
of  assertions  that  may  be  used  dynamically  to  evaluate  data  dependent 
structures  such  as  variable  length  and  repeating  data.  Figure  A2  shows 
a data  network  for  the  DEPSAI.E  function,  for  instance,  at  the  top  left 
is  a tree  structure  showing  the  component  fields  of  a tree  structure. 

The  arrows  in  the  center  of  the  diagram  indicate  the  inter-file 
relationships  between  the  TKAN5,  INVF.N,  and  CUSTMAST  files.  The 
customer  number  in  the  sales  transaction  can  be  used  to  access  the 
corresponding,  customer  record,  while  the  stock  number  can  be  used  to 
access  the  corresponding  inventory  record.  Furthermore,  the  SUBST 
field  contains  a list  of  stock  numbers  which  could  be  used  as 
substitutes  for  the  main  stock  number.  The  direction  of  the  pointer  is 
such  that  for  any  of  the  source  records  one  could  find  the 
corresponding  target  records.  In  a similar  manner  the  other  files, 
their  components,  and  their  interrelationships  are  entered  in  the 
network. 

The  assertion  section  of  MODEL  allows  assertions  of  various  types 
to  he  made.  The  source  set  and  target  set  assertions  are  used  to 
specify  subsets  of  files  to  he  processed  or  produced.  Other  types  of 
assertions  are  used  to  express  decision  rules,  formulae,  and  other 
relationships.  The  "source"  and  "target"  headings  of  each  assertion 
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SOURCE  FILES 
TBANS 

Lsalerec 

"TE8M# 

“CUST#  

- ACTCODE 
-CLEHKt 
- DEPT# 

“TBITEM  (1:9) 

-STOCK#- 

‘-QUANTITY 

ENDUES 

CUSTMAST 

I 

i-CUSTSEC  £ 

-COST#  (KEY) 
-NAME 
-ADDBESS 
-BALANCE 
-CR  EDLIfl 
INVEN 

■“INVREC  1 

-STOCK#  (KEY) 

"ITEMDESC 

-SALPRICE 

-go  a 

"TAXCODE 
-SUBST  (0:5) 


TARGET  FILES 
JOUBM 

^-joubbec 

-SALE#  (SEQ) 

• -CUST# 

-JOURITEM  (1:9) 
-ENDITEM 
-SOBTOT 
-TAX 

-TOTCHBG 

SSLIP 

^-SLIPREC 

-SALE#  (SEQ) 

- DATEHD 
-CUST* 

-NAME 

-ADDRESS 

-SSITEfl  (1  : 9) 

-SUBTOT 

-TAX 

-TOTCHBG 

EXCEPT 

Lexcbec 

-SALE#  (SEQ) 
-CUST# 

-BALANCE 

-CREDLIM 


“STOCK# 
“QUANTITY 
■-SALPBICE 
- EXTEN 
-SALECODE 


-STOCK# 
-ITEMDESC 
■-QUANTITY 
~ SALPHICB 
■—EXTEN 


Figure  A3L:  Data  Network  for  DEPSALE  Problea 
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can  he  viewed  as  a temporary  measure  to  facilitate  implementation. 

Figure  A3  is  the  complete  example  of  the  department  store  sale 
problem  in  MODEL.  At  the  very  top  the  header  information  is  provided: 
the  module  name  (DEPSALE)  and  names  of  the  source  and  target  files. 
Then  each  one  of  the  files  is  described  separately  in  greater  detail. 
The  files  are  progressively  subdivided  into  records,  groups,  and 
fields  using  the  network  diagram  described  above.  Uhere  data  is  fixed 
length,  the  number  of  characters  or  digits  is  provided.  Where  data  is 
variable  length,  or  where  the  number  of  repetitions  varies,  or  is 
optional,  assertions  are  provided  at  the  end  of  the  file  description. 
For  instance,  there  may  be  a variable  number  (1  to  9)  of  items  in  a 
sales  transaction,  and  the  number  is  determined  by  the  delimiting 
character  as  indicated  by  the  DELIM  function  described  in  the 
assertion  named  NTR.  In  the  Interfile  Relationships  section,  the  two 
pointers  from  the  sales  transaction  file  to  the  INVKN  and  CUSTMAST 
files  as  shown  in  the  network  figure  are  described  in  respective 
assertions. 

Finally,  in  the  assertions  section,  several  decision  and 
accounting  rules  are  given.  The  first  four  show  how  to  compute  an 
extension,  bow  to  compute  the  sub-total  and  tax,  and  how  to  compute 
the  total  charge  to  the  customer.  The  next  two  rules  (TRSALF  and 
TRSI'P)  determine  whether  there  is  sufficient  quantity  on  hand  of  the 
item  ordered  or  whether  a substitution  needs  to  be  tried.  The  next 
rule  (TRYRF.PL)  indicates  that  if  the  desired  item  is  out  of  stock,  an 
attempt  should  be  made  to  complete  the  transaction  hy  providing  a 
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substitute  (SPBST)  for  the  desired  iten.  The  next  five  rules  define 
the  various  values  of  the  sale  slip  and  journal.  Another  rule  (EXLIM) 
determines  whether  the  customer  exceeded  his  credit  limit,  and  if  so, 
sends  a message  (F.KR0P1).  The  next  two  rules  (UPDOMANT  and  ADJ-BALC) 
show  how  the  quantity  on  hand  and  balance  are  to  be  updated.  The  next 
two  rules  (CALC SAL#  and  SLIPDATE)  utilize  built-in  functions  to 
generate  serial  numbers  and  the  date  respectively.  Finally,  the  last 
two  assertions  provide  target  set  criteria  for  the  exception  report 
and  saleslip. 

Figure  A3  shows  the  complete  listing  of  the  DFPSALE  problem  in 
the  MODEL  language.  Chapter  4 has  explained  in  great  detail  how  the 
MODEL  Processor  analyzes  such  a specification  syntactically  and 
semantically,  storing  the  statements  in  an  associative  memory,  how  it 
represents  and  analyzes  relationships  in  the  MODEL  specification  in  a 
matrix  representing  a directed  graph,  how  it  produces  various  reports, 
and  how  it  generates  the  desired  program.  In  addition  to  the  MODEL 
specification.  Figure  A3  presents  the  cross-reference  report  and  the 
matrix  report  that  would  be  presented  by  the  MODEL  Processor  for  the 
DEPSALE  problem.  Furthermore,  Figure  A4  shows  the  network  of 
relationships  for  this  problem  in  pictorial  form,  for  which  the 
Processor  uses  matrix  representation. 
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APPENDIX  B 


PL/I  SOURCE  CODE 

This  appendix  presents  the  PL/1  source  listings  of  the  important 
modules  of  the  'TODEL  Processor  whose  algorithms  were  given  in  Chapter 
4.  The  programs  are  presented  here  in  alphabetical  order. 


•PRr  CtSSl  •NST.$'4*(?,72,l  » ,N*CHECF.NC*  > ; 
chhcc'j):  p-cru): 

-/•  THIS  PPiCF^mcp  LCPKS  AT  TMC  Mf  XT  ITCMICS!  TN  THC  "F\*  CT  AD"  ( ENO.Ta  3L  E > 
TC  SEt  « h I V I • 2 ■?  ANJ^rrC"  ST  ATpMF?'T  f.CFCS  TP  >rLL<~W  THIS  NCTC*/  " 

cuci  i VCc*t Ap_cr  n pasfoTf  e," 

2 \*:;ne«  fix^c  ein.  * 

2 ITPF  CHMKIJ  ” 

PCI  J FlxCJ  «!»•:  v 

/*  j THfc  riispcM  i\r*px  tc  thc  crcer  vecrc®*/ 
cci  CKoe3i«i  cixft  eiN  f x r ctl: • 

CCL  *LCURS  F I X f C ' *?  I V F X T*;  ' * "** 

r.  cr  in? •J'SIOFTFCTfC  ny  •PICWCPT)  ENTERFC  IN  CC  ANC  EN'C  TAeiES*/ 
CCL  *6  Mi  FlXtO  3|\  STATIC  IN  I Ml); 

CC  L cNO  T A t.  ( n I F rx  = n PIN  CTl  *XT; 

/*  T A jL  t LF  INDICES  TO  VECTOR  AFTEp  WHICH  "EKC"  STATEMENT  TO 

APhEaR  */ 

- 1 f s N i>  nice p?  tmc\  pctl°^; 

-'JL  V»  H 1 L u It\~TAh  («FNO)  -J  ) : 

/ •GE'iHKAT  c "f  Mf  ••  CL  CNCH  A 0 T ENTRY*/ 

LGCATe  HO«*rftVM0  F UE  ( FtCwTAtJ ) ; 

NC.U  »«CC  ?f  R (J)  ; 

TYOfc  »«PN.V : 


IF  iLun>«l.rno$  thEx»  RETURN' 

o end; 

- i\L  CrPCENO; 


*PF«  Cz jSI •' S *,*-<> 3 
CFhCLAd:  P-'Cl’i'Tt 
/♦  r«lj  p#»-*c  CnernS  IF  any  LAPEL  NFECS  TC  ®E  CFNFRATEC  AT  THIS  PCI*lT  */ 
net  Cfxcr  p|v- 

/Cl  L *Aa*_LAL‘ELS  FIXFC: 

YLl.L  vtX.LF*-.l  AKEL  FIXC0: 

?VA  X_LC‘I_L  AjrL*  14  ; 

*****-(. AdcLS*  t T; 

Jf.L  l r l rW  T A L A®  P A SEC  IP), 

2 \rn?¥  p Txcn  kin. 

2 r YPE  CMA«f4)v  / * I AO*/ 

2 1 A°?L  CH/.c  ( VAX-LrV_LAFEL  > J 

_ CCL  . LA-iLI  ’AXI.l  A«>f  L?)  f_7  X F C_  P.!N_FXT; _ 

'JCL  U4fctL>  FIXCC  PJN  F X T ; 
n C 1=1  TO  'HaaELS; 

if  .%•*■«?  *l/.pflif)  thfs 


CHECLA?* ) 


/•  GENERATE  LAV:l*/ 

JL  CL  AT  c Fl  C*  T A P_L  A p F T.L  F ( F_LC*  T.A*  ) T 

Fl  -VtT  A*_LAa  •MiCE*’»0; 
r L."  V*T  AN_L  A?  . TYP  c = 1 1_  T P • ; 

?Lf  S TE  T'.»»  ( FLOW  T AF_LA*»#IA9EL  ) E C I T I • *|.  • , \C  CE  ) <A,0«'J99*| 
L&  irl  ( T i*o: 

/u*n  THAT  LABEL  W II L NEVER  5 S CEMFPATEC  TwICE*/ 

Return* 

eno; 

c^c; 

t^U  CFfcCLAH: 


PF 
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•PhUCESSI •NSf#MAC®0*S**(2*72»ll •K«CHECKCC  • I 5 
CHECkDC:  PROCIJI; 

-/•THIS  PPl.CSnijpe  LOCKS  AT  THE  NCXT  ICCATICK  IK  CC. TABLE  TC  SEE  If 
CUKkEM  NuCES  NcEn  A "nc«  STATEMENT*/ 

*CCl  max.LCN.px  I $T  FIXED; 

?tCL**HAX.LVNlF  iR^ACK  M xEC; 

XCC L max.LcN.mahF  F IXjECl 

*MAX_LCN_F*I ST*32; 

XNAX^LEN^NA^F* 10 • 

tK AX_LEn”F0RE  ACM*  1#  V 

CCL  J FIXED  BINS 

‘7*j  ':s  the  c'uRppKf  index  tc  the  o»c*r  vector*/ 

/ * l NUfcX  TC  OC  table*/ 

-TCL  biiC  FIXED  HIN  SlATfC  |M  I ft  I H 

OUCL  UP to JUNO  ENT^YICHAPI  *)  fF  ixcc  P IN  ) RE  TURK S < F I X EC  9INI8 
CCClI  UPB  vxSuhs>f  IX Ell  flpj; 

/•FLNCriCN  WHICH  retup  vs  CHE  fPPfg  fafe-NC  CF  A REPEATING  CPOUP  OR  FIELD 
‘ /* 

/•UPe-.SET  to  upocunc*/ 

/-rfSJUS:  N'J^PFP  CF  SUBSCRIPTS  PE  REPEAT  I KG  CRCU®*/ 

ODCL  CF  DC  ? I * ) FIXED  BIN  EXT  CtL*. 

CDCL  FcPEA  TP'G.OOOUP  CHAR  tf'AX_LEK_K/NE  | ; 

/ *\ A.v E 0F_  GSCMP  OF  FIELD  THAT  REPEATS*/ 

OCCi’fLCCPS  PfXCD  PlK  EXT; 

/*NU*<bF*  Cr  LCD®  $ DCT^CTEC  PY  •FlCVCFT*  EKTFKEC  IK  QC  ANC  ENO  TAPLES*/ 
CCL  I FLCklAP.on  pASECI P I * 

2 f.COE*  FIXCC  OIK, 

2 TYPE  CHAP|/,)t 
/•rypp'oo  • */ 

-2  ^u'ticH’f.jMC  C h'aR  ( m~a"x  ^ l E K „ E C P E~  A C hT#  

2 'iPPfcJ  .TYPE  CHAR  ( 1 1 • 

/ ■ F * F f a F 0 ( C C*-1  S T A \ T I ‘/pppa  ®CL  AC , V*  vac y f \G  UPPE®  «C»»NC*/ 

2 UPPC3.1  FIXED  DEC, 

2 CHAP  IWAX_LE*..EX  IS  I I 5 

/•FijrfCFiKr  taplc  r\r»v  ?r.s  cc  statfncNT«/  __  

CCL  L C-r*T A ■'(*)"  FXT  C!L»  ” 

2 i rc  ci  xfc  e in , 

2 f'C_Lr'0P_V ap  Chap  (UAX.LE  K-FcpE/Cf  I ; 

/•Cl'TAb  rJLLfn  Ay  Fi  OWE  P T ;|.f  C : I »TcX  TC  CFCE®  VECTC  P GIVING  LOCATIONS  OF 


"DC**;  00— LCCP_V  A®  ? HFno  c AChm  va*IAPLF  Tha*  ccvcp\$  ITERATION*/ 

IF  f»LCDPS  TH F*  PETfPN; 

CG  JH  IL=  I LX  C *'30  I =J  ) : 

0 ri  t Pr  AT  PT»_r»u  ftipx  ?*•?  T P I£*r— LCCP.V.*®  ( FCC ) ,0  I • 

_c /*FI.\n  ' zut  n r f P PPF.*  r f vr^rsTL®  C®  FfELC*/ 

UP8*UPu';ijnOI  p EPF  at  ?\*G~CPrtP  #*SU?C.  I," 

0 IF  »JP»*0|  *S'JPS=D 

TH£.N  DO: 

CALL  PNPT  ERP  ( • Cl*  f^'lS  ICTFMCY)  : " • | | X_lCC®_VAP  ( PCD  I | | 

' " C*0?S  HCT  COFcES°Cf;r  TC  A FREEST  IMS  GPCUP  OR  FIELD'); 

_P  F T'JP  *‘!J _ __ 

fc>:C: ~ " ~~  ~ 

3 /•GfcMFFATC  »Cn«  pLrW(-HAoT  cntPY*/ 

0 LOCATE  FLOWTAP.Or  F 1 1 F ( F L C W T A 8 I ; 

fiCJE  TsC^DE®  ( J I 5 
TYPr* • DO*  ; 

Ff.'P  Z AC  A.ML  »DC^L  fCP_  VAP  (jt  CCJ  i 

0 i‘f  kru^s*"i~  Then  nc,  ' * “ 

yppC^_TYPPa»P*  ; 

•JPP?R  *«Up0  J 
ENCJ 

0 ELSE  oc; 

UPPfiP  TY^E*  » v«  ; _ _ 

'ippcp"\A^ra  • = x fi  t . • i fpeV’tYnc^grcup:  "** 
cnd  ; 

- ’ * »0C*  *0-1  ♦ IS  ' 

IF  tH-<>  ilCCPS  THEN  PFTUPN; 

o cno: 


1 

2 


3 

4 

5 

6 


£?*£*&  i*. 


• phi  crss(  • macro, ms t,  fx  j°f. f ,N*crceGfN' »; 

. CUntGEf::P»  3fj 

/*  THIS  PHOCC'JUVc  uses  THF  TLCUCHARr  RECCPCS  TC  CALL  THF  PQUMNES 
WHICH  Ol1  THP  <*r«nr  '•,rI'4tK'AT  1PK.  •/ 

CC  L l F l C W f .* Q T p Y_ P?P  TC  riMSFC(FLCW_PTP  I , 

2 NOOC*  F1XFO  «M*lf  

2 MOE.tyRF  CHAKK), 

__UN  r I L . E ) F__  \ I f C l 7 |\  I T ( U V5* ) ; 

uk  f.npf ilc ( flcwr a?)  r'r  "tc 'f  in  ishjj'p  ; 

O/*  we  PICK  HP  The  SfCf'POS  Per*  TH  = Pfie.  thf  CN  ENOF  1 1 F WILL  TELL 
Ui  WHeJV  We  A?  F COM.  THUS  ThF  ff.FIMTF  LCCP.  */ 

/•  CPE.\  thf  f *1 P 1 1 T Flic  WhICH  will  Pe  USFC  3Y  THE  SL8P0U  TINES*  */ 
OPtN  FILE (FLCWTAF ) INPUT  PECC^n  FCCUENTIAL; 

0/”L  Pr*l  ALL  {Hr  OUTPUT  P L /_l P. l_L J? S/_ / 

" CP*M  ILf  iPLl^N)fijT>ljT  ''Rffr°0  S F C l » 

FILC  (P'.lcX)  riirPL-T  R c C'*  F r SFCl,  

UlUPLIPruCIOiitpuT  OFCPFC  SFOL; 

-LCCFS  uO  wMlLFCi|F:TlL.«f'%el  5 

%6A0  F I I.c  ( =1  iwr  AH  ) SF  r (FLCW.PT?  ) ; 

IF  NcCr.TYPf>«&5S.N«  TnfN  CALL  ,C9PCCC0  < FLC*_P  fP.  I ; 

cl  FT  oo: 

IF  NUOE.TYPFs «PFCO 
clSf  un. 

IF  NCJc.TY^C  s ' r l 0 I 
cl  Sc  OC; 

_ I F . MuCr_T  Yf,c«>li»-Tl»  CALL  Cly.riC  (FLCW.PTP  ) 

cL?c  on; 

IF  :.wGF_TYT»r»  ,f,PT^  • ThFk  CALL  GEMCCClflC 
eLSF  00; 

IF  NLCL.Yyor 
clcT  On 

IF  JO  L F _ T Y p r * 1 :*■  C T C 1 T H CK  C ALL  .CEMCTC  (FLCW_P  To  ) 

ELSr  n j;  ' ‘ 

IF  .NL  Cw_T  vr  Pr  • L A R • THEN  CALL  GEM  AC  ( f LCW.P  TP  ) ; 

ELSC  0^: 

IF  NCoC.TYPM  • -MV  ^cm  call  CC  NFA  n ( FLCW.P  T P ) ; 

ELSE  nr; 

IF  M'iCL  TYPF-^n  T HFf.  CAM  CENCCifLCW  P TP)  ; 

LLSF 

IF  .-uOr-TY«'Fs  *PSFT  • THEN  CALL  CFNF  SF  T (FLCW.PTR) 

LLSe  PC; 

I r N('OC-.TyPc * »rrvn*  THEN  CAtl  PENCrr-.C(cLCV^  P TRI 
= LSE  jr; 

IF  \f!f.e_TYPg«»  TCyT  1 THC*.'  CALL  C t h TC  X T ( Fl  CH  PT* 

FMJ  LCCP; 

OFIMbh.UP: 

0/*  CLLSC  CUT  th?  I'PIT  FILE.  •/ 

CLCSC  F I L £ ( rLC  W TAJ);  . _ . . 


THF ti  CALL  C = N ICCC(FLCW_P  TR  ) 


THEN  CALL  C I *Fir  IFLQW.PTO  ) 


PTR  ) 


TFf N CALL  C'CCCT  (FLCw  PT3) 


/•CLCSe  JUT  TM|.  C U T r L T FILES*/ 

CICSc  F iLffPLl.!*')  t F ILC  (PL  LEX)  ,F  ILC  (PLIPPCC) 
c M C C L C C E ’ . ; 


• PROC  tSSC  *NSTtMAC°C,Sr**(  2*??.  I ) *K*CeC  n*.T,  EXTBFP*  ) : 
cooler:  pw.c: 

/»rHis.jpaTC.«:ru?F  CPFATES^A  rxrjiCKAKY  cc«f*ESPCNniNG  a Mu^e«=R  .to 

F *0*  P'M.  I Y Ot.'AL  f F I E P f»  AMF  •/* 

5 iNCL'iTF  INCLt*  (n<EC!f»)S 

3-.  ;\CLUn:  INCLIS  10 AMY); 

A INC  LU'C  INCL  IQ  (PASSIM)  *, 

iuCL  MA  X c T>T»S  HXtCS 

ff!C  L Ki  *__L_r  N'.NAP  fc  Pj 

= tpt«j<  *20C  ; 

“•.max^l^n^na  *f*  10 ; . 

* i nc  i u>  c”  i \c  t.  m «'r  i c t ) : 

?CL  CHPT?L°  ENToy  (C*-a*l*))  RFT'JPNS  ( Chap  ( i E N_C  I C T.EN  T®  y » V AR  I ; 
OCL  PRINT.LINE  (•**=(  120)  PASECIPRU; 

CC  | hkL  _ or\  N'  Trc  _S  T AT  ! f._:_ 

Jv-L  ST  ^lTY?F_*or.sfV  CFA?7a  f STATIC  J 

OCL  CJ;<ir‘.T_.''^f.0r3(vM3_!3npnsi  PCINTEP; 

CCL  ^ I'  .KpY-  ( iir*  iFf\  ) PC?r  ?FP  CTL  F X T ; 

/*r.\uL-”°c  rc  di^ectc-y  entries  \"  alphapemcal  c*c?ep; 

al*e*~y  all rc a r £*)  ANO  set  ^y  •XPEF**/ 

>CL  * M - r .c..l  XF.C.  e IV.  ; . 

IS  \il*pro  C F ENTRIES  IN  ClRECTCPy*/ 

L>CL  clX  = 0 MNJ 

/•«  NUf*'-.fcR  !'  p”*STC?' Af-E  rM^lFS  will-  xa^F,  S = T pY  ' 3 E T«  F VE 

ocl  |MTrr.  cxr ; /•nrrM'fc**  rr,  *Fr. inning  cf  oipcc tcpy*/ 

CCl  CU“  - F\  T .f'  Av  = rwAW  (vAX_Lcr  _NA^t  ) STATIC*. 

UCL_  't.S-EVr  ’f  *;n  y(L.*AP<?  IJ 1 Tf  TC=AS(C  ITU))  J . . 

Go  i = i to  “ ° I - ? ; /•  f^p  F/r>  riPcrrrwY  f\tpy*»/ 

/*ser  rii:fr"-T  ^riNTrsi  rc  »:*<r  *iP>«*fc£T icjl  namt*/ 

J Ir  fc  . r^-' v_or?  _kfy  ( l J ; 

C'JPP  r *:  r_*.  VF  = KF  Y_\ a VC  ; 

IF  >YSTe*4.ASSIGNCr  NAME**/  Si;°STF  (CLPPrcT.f.AMS.  I . I )=  • « • THEN 

ELS*,  f r t'  T^NAV-:*  #__  • T*-Cj;  /*  C L A * " ,N  A *•  E $ */ 

cL  Sc  Ip  •’FScp'/fTcL7*’1  R\ r_».AvF  » Then  ; /•  re.NT  f>«GC.E$S  ’-srP'/E0 
_ _ _ writ's  *f 

ELSE 

c-j;  /r  • IS  -a  l 5 * C£  f J n*  C A /-  M g **  ✓ 

/"•FT*-  |';VF  all  S T C ° A 0 F «=  f - T «■  ITS  H TF  CURRENT  _NA*F*/ 

X.*u._a  rlP<*Yf  (C'/'HJ-  r‘  T..‘  * v fc  # • »ST  * p T ,CLF-  ENT.N  v-*c_PT^  , 

aC'IF.^FN  T _*  A'#r-Sc  » ; 

DO  J=1  TO  <*f.  UF  = Efc  tI»  ; /«  FCR  cACh  CF  THE  ®ET*IF.V60 

rttpacf  entries  v%  i t h chrjpnt^name  •/ 
STC'  AOE^P  IP  rCU?  REN  r«^.'.yE«.RT°  ( J ) ; 


p = 0t  T a^p  T ; 

c CMPPrr.T_NAyt  a N A V f ( l ) »hFN 

r*.  /«  this  is  tmf  st/.t«mfnt  uhepf  the  cup^fnt  ma^e  is 

GfPfurp  ■/ 

S r**T.TVP«-_AO,<erVaSNv-<  rvT  ,7YPg  ; 

CALL  V jT  •‘T  r 7 AL'l  ^ri.TlAh  TC~  t?o  Af*CH  CN  ST-I  TyPf  AF.-O*  THEN 

f.'itfo  >jamf  in  r.KT  ACf.r»n irrcLv  ♦/ 


” / * Ef.T s”  s ° r r I a L rAP«S  !NTc“"Th€  CKTTc’narv  •/ 
st y r .r ypc_ pvs  • spcn • : 

CALL  Sr  Tf.CLPf  »CHPICF  • ) 5 
CALL  C-  TCFL3  I »FX  I ST  • > : 

C 'LL  c: rr FL 0 I * L F \ * I ; 

CALL  C’rTCffl  P(»p-f*lTF?  _•!*,  _ 

CALL  G".  TC  cl  p ( • Su**  Sr  r » i; 

CALL  ilPPfTT:  /•*•  O"!  nif  r IV  AI  OMOETfrAi  fPOrP  •/ 


r 
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13RSTVT:  P’->CC; 

/•mis  ppicenupe  cctfr’mnnes  who-  prccecure  tc  call  tc  enter  the 

•CUtWt^T  NA4P»  tCCcI\cC'  I \ Thb  ~LfiP=\T  ST03ACC  FNfP  Y CF  Type 

• ST4T_TVP=,A“3  >cy  ♦ ) A $ A FIJL  L Y CLAL  I F I EC  NAPE  INTO  _T  h E 

c ic  r i • "aoY  ('pict'i  *7 

OCt  PA-c.‘-r  c*  r?y  tPCl"r~P)  DF7U°\S/CHAR  (vax.lEN-NA^E  ) ) ; 

OCL  I £* P_h A^ENT  CHAW  (''AX_LFN_NA,'E  * VAR; 

IF  bT  iT.TYPr^A^PR ?y * • Pen  • then  Call  f n t y f m ; 


JlSc 

IF 

’■_TYPF-.A'»‘!3FV*,aSTC' 

J>c\ 

call 

EMSING; 

rL  Sc 

IF 

ST,,T_7Y{)s.'i?Ci''EVs  * ASS3  ' 

Th£N 

; 

f L S t 

l r 

S f“  T TY?F_4-*W->f  V**  A$TX' 

then 

; 

/•  • : 

Si  ' 

,\:.n  • A 5 r • \A/'=S  nr  \C  T OF  T 

fMESEC  SifJCc 

•N  At  • r 

HAS 

AL’FAOY  ArE*I  ENTEHtC  I 

N * A s T G 1 • / 

iL  a h 

1° 

Sr'T^TYPE^A  \«RcV*  •G**P  • 

TH?N 

CALL 

EN  TMEM ; 

ELSE 

IF 

ST*  f_  TyPf^  \ 1 = '>  Cv  = * I*  T = * 

rwf  \ 

CELL 

C N T I NT  a ; 

iL  S £ 

IF 

STvr^TYPr,A'iy.<Pv-,F!Lc' 

T h * N 

CALL 

c N I f t L F J 

b L S r 

I? 

3TMl,TYCr,'.>>  1«pV*'-FC!V 

T H F ^ 

CELL 

FN  TRCCC; 

I L St 

I F 

iT'*r^rrPf-i‘i%rys'r  ppi« 

THFN 

CALL 

FNTS  INC; 

clSr 

IF 

T*.*T^rYPt'^AOnPrV*'PPT'  * 

THF  N 

CALL 

fntsinc; 

hLSF 

IF 

S f y r _ t y p h _ a ^ .•  p f y »«•/,-  r l • 

Thr\ 

CALL 

c \ T S INC; 

cL  Jr 

n 

S T * r_  T Y P F_  A ti  C * r v = • M S X * 

thfn 

CALL 

ENT  sing; 

FLSr 

IF 

S T *•■  r_TYPF„Aa  =pcv*  'Pc  AT  • 

TH  r N 

gall 

TNT  SING  *, 

CL  jE 

Ir- 

s r*  t _ t y r r 4 j-  c v = • c .*  a r.  • 

T H r \ 

C/LL 

t NT  S I N G ; 

cLjE 

IF 

S T-  T_  r Y P £ _A  3 AS  c v - « T H ? • 

ThP  F 

CALL 

fntsino; 

CL  ic 

ic 

< T *•'  T T Y P *■  A -•  m i C y - 1 T r c V • 

THt  N 

CALL 

en  rs  I ng : 

:L  SC 
EL  St 

IT 

STM_rr?^_A^p•-;cv=•?rC^-, 

THPK 

CALL 

ENT  SING; 

!'  *CL-C 

hc  Cf0CCTrFv 

was  Frevr 

AS  F l n S T 

i T :F 

r,  - 

ENTRY.  K‘  <cV'},  T Hr  STC 

> AGE 

ENTRY 

s r atfmen 

ECU’. 

j T~ 

°F  illegal*/ 

CALL 

S Y S E J 9 ('r>'Y_TY>’l:_,Y3”‘:«Vll 

' ILLEGAL 

STMT  TYPE 

IEMSI  NO : P*nc; 
/-THIS  3'-rC 
•';lamks»  i m ' 


cvTrpc  ThP  SlVCLf 
Ti-.f  r I r r h;f’  A3  Y*/ 


T T Y°  F WAS 


1 CLPPFNT_*  AVF  • (WITHCUT  TPAfUNG 


CALL  c JT.ilC  r(CHPTPLM(CuFPENT_\A*'f  I ) ; 

ENC  ENTSInG*; 

IE N TINT0!  PfcCC  ; 

/*  T ►-  t S ?orX.  will  FVTFP  ThF  f U®  3 f.NT.N  A-  E , AN  INTERIM  NAM  E » 
THfc  PRCt-I/  • i**rec|v#»  |fj;  r»-c  n (CT ICNARY  V 
CALL  C* j T n I C M • I’  tc.'!v,  • I I Chpts  lpicopfn  T.aamE)  ) ; 

"«■»•>»  =\TI\Tr; 


i l TH 


* t 


UMwcMS  PR.:  C; 

/*hTifi  »C»PF  FNT_NA*e  • , \ rjf’CL'P  ro  cietc 
TD  wUflLlPY  ! T » IN  The.  r r C T ICNAPY*/ 


in-  »rs  parent  file 


TFMP^F  Af-  c\'  T = CHt'T'*t.tM  c 4Wf\T  | ^TCP-iC^.PTP)  ) ; 

/*  'ff.tW’U'  •'III.  FNTs«  ThF  CUAimEC  NA-vE  WITH  ?OTm  ocprixSS 
•III).*  A*c  •Nr'W.'  CM  Y l*  Th?  PARENT  Fll.f  NA.Mf  1$  30  T M AN 
INPUT  t-K  'A  OUTPUT  r ! I f : CThFR-ISC  IT  ulll  F N T c ? fuf  Of.A*F  IS*/ 

call  o( t-_cmc>_p.*.cc\  r jl I * . * l f optics  ccuf ®ent_*ia*f  i # tfvp^papcn  n ; 

e.\r  cNT-ie  4 ; ‘ 

IEMFIIF:  pffr; 

/■*  This  jr  *Kl  EN'TFP  THF  CUP  P f N T.N  t m f # a F I L F NA*Et  |f;TC  C IC  T •/ 
T:. c^tsCh*0  TPl’’  ( C IJPP  e\T_N  A ) : 

/•  '-III  r \ T p o n-E^FUF  N A ,v  E v I T h PCTh  POfFlXTS  'etc,1  c 

•s-'i.'  "MY  IF  ThF  eiL'  N A '*  f IS  PCTh  INPUT  f.  CUT  PUT  */ 

C All  e*.Tv,riLr,(  7Fvp_PAcrNT  , Tf  *P_P  i»£vT  ) ; 

t M y.  si Fiie; 

ICMcic?:  P'.CP; 

1*  T‘«ic  i»^r  r ‘-/ML  F T f n THE  CUP 3 FVT.NA^c  f a pfC-"*  MA*F,  l*:T.)  CICT 
c ail  c jfu^l  rM  " (cup-  En t_na"c i ,r Fprt  i3 (Prt« t'N r ( s -_o> rein; 

/'  • F \c  «'  l i * wm  fNrcn pfcraC  \AV6  AM:  al$C  m-E  ocFFlxFS  ,r'i0.«  f. 

nfK'  n :ly  \-  tmf  oarfnT  frf  cf  thf  °fcCu0  is  ar,Tn  an  input  r. 

CUTOUT  F f L r nf 
£NC  c\rkPCOl 

I F Ft  £ V uLU  : o*  CC  (0*  AMF  ,PAf  ) ; 

/*  THIS  P>f  C ,":F  T F?  ‘.N/riP",  ChECKS  hhrTHFP  THF  PAPFN'T  FRP  NAME 

*D/.ct  _ |S  4-  TH  •!>  INPUT  A VP  riJTPur  FIIF.  IF  SC,  IT  F N T 5 R S 

fH-  CU  • 3 C*l  T UU.'.IIFIFIJ  fit*  t * CNAk  F • INTC.  IFF.  CIPUCUARY  With 

fr.ru  r,4c  pFFFft  a.\c  'em.';  cthcrwISF.  it  Enters  thf 

;n^*'=  a s lT  is  in  r~»  n-e  crer  • / 
ici  i -F  ti  c FNT-'Yff  hap  (*ivar  i returns (e  rr  ( 1 1 1 j 
CCl  '.N£Mf  P!«.*.0(’»)  VAR; 

Of.  I p.v  rwfl3  |«|  V AO  ; 

"“‘if  n>  IlFI  PA.M  Thru" 


Call  ENT'AICT  ( »NFw.  • | |0NA*M 
CALL  INTO  If  T f • Cl  0 . 1 | IQNA^E  ) 
t\o; 

ELSE  CALL  r\XD.l  C TJ  On  am F ) ; 

eNCwriO J 
4 p r.  T m r : 


ICcTCtlP:  P*nCfC?ip>; 

ICCL  k.\x«.C?LP  FlXECS . . . 

tMAxx.c€tP»sc: 

/_•  At'  _.Tw£_«  LTNCTH*  * 'EX!<T»,  • CMC  ICE*.  * ANC_  . 

•i>Dl\rrv  A-J  r •SiiPSHT*  na.^eS  INTC.  the  0 I C T I CNAfcY  */ 

CCL  T:;r.Ayc  Cm  (Lf-'i.r  ICT_PNTPY  ) V3P; 

cll  cflf  char  im:  7«  •cT'-fcr*.  'Sxi<;t',  *ien*,  r®  'pointe**  •/ 
rcL  CFinr«.  »r\Tf'Y (CMfii-  i«ivap  ,rKA«y(*n  w6Tu«?MS(ei mn  ; 

OCl  tlCT=X  6\PY  ICH'.ct»lvAR)  FETORS  IPITIl)); 

UCU_.Ccu?.p.L»_.I^ax«_c c^pj tp«j.  

/•Pul*'rts  rr  T » I e S «!T*  a • C E l P • KAPfc*/ 

OCL  «uCLp_Pro  PfX.ff-  P|*>; 

/•  MjPj*cis  r p rNTM*-S  WITH  a *r.fLP»  NA*E*/ 

/•  fiEf'IcVc  'll  STPRAOF.  p*»R|I:S  with  a 'CHIP*  b A y F • / _ 

CALL  «cTi-5VF  (CEl  P»  * * *STA»i  T tCriP.PTP  tRCFLP.PTR)  S 

Ou  1*1  r:  »CFLP..PTPs ....  ..... 

/v  cno  c>fH  S TC® ACt  "Vn  T p Y WITH  A ‘re^p*  */ 

S TGP  ao6_P  T^*CPLP_°Tu  I I ) • 

OP«Hf.  T a_  ® T ; 

NAVE  p;^«2  ; 

Or  j*i  T'*  #nmS; 

feACH_0«JAL  f FIcO_  ^i‘'c  I\  Thp  CU°P  eN  T STORAGE  ENTRY, 

° = T‘:?*'f».f  .WFTHFP  IT  IS  ThF  'CELP*  NAME  */ 

IF  *!/.*?  (f«.At'rpir)*CFLc>  Thc\ 

OC  ; 

r^MA'Af  «CMf*TWLi3lNAME!*.AY£  INC)  ) I I * . • ; 


[e  <c-.MpfiCA  TS  ( J ) *2  TMFN 

ro*' i *c * r c*; * f|  i c-ptvip i \ Af» f (\A?e  i xn  *i  n ; 

51  SC  ! c rff'-'*'®' ••:£  * TS  ( J ) s ? THEN 

r 0 \ a •«  r * I ► v*  K I I C T 5 L ■»  ( r.  A ► r ( a a w c ( v C ♦ l » I l I • . • I I 

- t r (*  AMC  ( •,'»(•  | «.r;*2  ) ) ; 

‘LS*  C*LL  u\r  T«-?  - l rr*.A  'f  | | • l L i E 0 <*  L 1 I I CFl  » I I • ' X AM?  • ) 

IF  ««^ICTr)iiTOV''pi  then 

I c C c L p C k ( T C N A v.  p , C F i P I Thta  CALL  EMC  l CT  ( TGNAMP  | ; 

c m«; 

a:  C I MG  = n A M c ; m:  ♦acr.YPCf.FNTS  ( J ) ; 


■:o  1C  T w X : pm.  C 1 1 pf  n jp.s  ( J iT  ( L)  l ; 

/ * T h I j P^JC  :6TF-^l\tS  IF  • T G N A M fc  1 Al^EACY  EXISTS  IN  Thp  C I C T I (I  N A P Y 

*/ 

CLL  T,\A,,'t  CHAP.  (•)  VAP; 

oo  * * i r ' jictjko:  _ 

IF  ^ IC  r l«C|»  TCNA^F 

THC  . Tijh*:  ( • l • a ) ; 

ENOS 

*cTU*N  (*0*01; 

Ctr.L  DICTKx; 

OE.'.'f  GcTCp’lp;  

IcNTCICf:  F • CC*‘  ( ' irre*T>T 

/•TmI  , ®POC  ;UHF  FNTrPS  'CICTcNT*  fKTC  THE  CICTlGriA«Y  */ 

CcL  cur-f  C M»c*)  VAF  ; 

CICT  *0  1'-  rpn»|  ; 

ib  jcci  r j>  I**  the?  call  sysfhf  i • r i c t size  exceeoeo'is 

c L Sc ___  _ 

'i'l;  /»  :'rTfJ  U-f  a »•  o T Y p r INTC  Th'f  r'ir  TICNAh  y'  */  " 

OICM  nrr  r i*j  i * ciCTcnt; 
wiCTYPfJnifTlA'ri-STVT.TYPg.ApapfV: 

P.NO ; 

FN II  cNfGICT: 


. t ^ 


1.2 jJL  I .^CYCLES*  I 


i*c  acor*i  rr  n; 

00  K**LCT  TO  N ; 

>•  6 AChJ<  K ) aRGDT 

us=om  * • o • ^ : 


•PATH.tXTENnFC  r k 6%l  oc 


h 6ACHJ< f )*0rPT 
CALL  9ACKT*ACK 


/•  hsT ERfiAL  SUnor'l'T  l\cS  -/. 


RAC*T>ACK:  pcoC;  

UScR(  I )■•('•  Rs 

Lcvn?irvFJLri; 

if-  lc'/pl-s)  rnr.v  r *PdrH(t tvet i 
F 'iO  f*.  a c k T ° \r*  ; 


fcXTENJ.P ATMS 
USFr( J ) = • l 

P z •**  f.  r J ( f I 3 JJ_l . 

L E V t L * I.  F V c L ♦ l 
P A ThI LCVCL)  -J 


PPOC 


PRQCi  $TR,OELCHAR  ) RE TUR N $ ( f I XED  BIN); 

UPN S THE  NUMBER  GF  CHARACTERS  UP  TO  THE  SPECIFIED  OELlMSTfR  * 
’*  CHARI*)  VAR,  OELChAR  CHARI*)  ; 

1C  INDEX!  SLeSTRl SIR , I ) ,PELCHAR)  -I)  ; 


LEVEL3 1 * . ... 

PATH!  1 ) *<mr  ; 

I*p.ccr . . 

uu  whilf(i.cvpi—0)  ; 

V M h_C  V T F*.  OFf’a  *0  1 a ; 

JVlf.^FAOJ (I)  ; 

oj  rr  m w*-* r l r ( ( i.pvfl-**o  ic^path.sxtenceo) 

ip  •'*  f ! , j ) r. p ( j . Pnri  r > r.  -*u  S C c ( j ) then  dc; 

PATH_PxrpunEna* i • a* 

C AL  L ™p  X Tcf-?0_'*  a TR; 

• 

ir;  j»-*cct  thc*.'  00; 

CALL  °ccvr L? (PtTH.LFVEL) ; 
call  *ACKTa AC* 5 

•PMl-CESSt  * NST*  MACPP*  SM»f?*72*l)  ,\*fnc.xcp,e xtrff*  i : 

ENCXUP:  PRf.C? 

/•This  PRnceniPf-  EMTgRS  ALL  the  EXPLICIT  C6PE\C£NCY  *ELAT  ICNSMPS 
t Given  I'r  »Sf.P  A S s TJOAJJ IN  T F g 

ADJACENCY  M\TV|*X  '•  AC4i"S  T •'•/ 

TiiCL  MAX. I f FIX6C; 

XCCL  rxPL.'ieP.CCCf  F IXEO ; 

tsti  iuu'_ncp_r  ^oe  f j *cp  ; _ 

3*A»jir».';cP.ci:r/5*3: 

ACC  L _ .v  A X * .AS  $ E **  T F I X_E  0 : 

~ XU  “ L * y ••  /_L  - N . N'AM F ” F f X F Q • 

*CCL  ► AX  *Y.®  TP  cjxgqj 

XCCL  C::NC_u6PlcnCE  FIX60; 

tCrMj.ucP.C.fOr*  7;  _'_j_ 

t.MAX  *_e'4PTY_OT;*  *r, 

r iax^cfn.qhm*  32 ; . ; _ _ 

<cX*l  JutP.C^fcEO; 

^AX».ASS«®T*lO05  

«:;*ciuoc  incl  I p (csfc  tR ) ; 

tP&luufc  p:CL  I P fi'PIC  T I ; 

{ I *(C  l u£c  IN  CL  I i!  I QASSNM)  ; 

“tecL  ’MixV.L/bFi^  f”i xffc ; 

A*AXrf.LAv £LS« 10; 

CCL  L-^'i'L  C^AX^.LARFLSl  *1**0*  '•I*  EXT;' 

C CL  UAJcLS  FIXPT  -\jr.  u^T  HITIOI; 

JCL  C J"0PaiT_A$>rpT_fcAwF  O AO  (,V  ax.LF^.N  five  )\n<*  ; 

•;CL  CJ-’TPLF  t?  ravTOiw  ( « I l_f  = Ti/Sns  (Chap  t vax_lFn_c>  * ) var  ) ; 

' CCL  rt,\4»e~‘r.H£z  / » /»X.L  E>  JC\*  )VA°  : 

C'-L  i.jjr/ATCOir.Tir  f»#riCTl\CiF  txer  PIN  EXT  C T L ; 

CCL  s I . I 'iO  F l x c c 1 N ; 

CCL  C C N j f\^T(',Mi<*{»|iv«rijovs(*|riin; 

CCL  OIC  1*  aM^Y  (CHAP .(  " I V4i!  )Pt  TH0\-S  <F  I X?C  PIN); 

_ LC  j.  vL-^A^f  E>,ycY  IFlXhC  * !>• , F ! Xft:  3 I N , Pf  I \'  T £P  , _ _ _ 

rixp  •.M'.CFAPP»Va«tfl|Ml)j; 

?Cl  TaY.-nt?  to  ix  'MTU); 

CCL  STa«T  °r  int  f ext; 

CCL  ASSE^T.P  T-MrAx^ASSF®  T ) F C I N T E ° ; 


CCL  MASS*.  TASK  I FIXFC  *1  *; 

)CL  svrty  !Cfx:o  Pp, FIXFC  PIN  ,CC  INTER  ) RETURNS 

I CHAR  < ••••X.L-'i.'.’N  )VAt  ) ; 

CCL  kA'iSF'T  Fk**?  ( ^ A y _ L EN.NP'f  ) IM  T ( MASSEf-T  • I ; 

XL  E\Prv  ChAft  ( ?/AX.L A vC  ) I \ I r I 1 FvPTY  • ) : 

JCL  Lhjic*  '■‘-r-  I-*  *x.l  r.\'.f,A^£  ) IN  l T ( *CFC  ICE  ' )i 

PCI  e vr,TY^1'>ro  (M4X1_C'.'PTY_MTP  ) PClNTcPj 

f'C l <*c*nTy.»T3  fix”?  Pin 7 

ccl  Tcvf.tI  R.rrtr  c.har  i ^ax.len.cnm  jvap  ; 

OCL  p POl*jTFuf  ;>or-_iiT!'  ft<ro  ? I EC.  P TP  ( M»  ) C0INT9; 

CCL  fc-.ICO  CHA3  I '‘.'.X.L  F‘:.F  AyfJ_  !MI  T ( • SKSCO  • ) , S*»PTN  CH  U ( m AX.L  EN.NAM£  ) 
i ■*:  n 'ty  pT*.  «i  ’ 

Cd  f U.L  ‘.Ar  T_*r  T'-'cVr  r*MR  /••'AX.LFn^na  VF  ) ; 

CCL  FILcST  r?TR  Y (CH  AF  ( ^ ) ) - t T'JkNSlCH  Ao  < ? ))  ; 

CCL  M«.I.S:.Ty?=  CM AP  ( 2 ) J 

HCL  ^‘'c.rn  c^f.'vc  c MAS  ( VAX_L  EN.N  AVF  ) ; 

CCL  "tCNt-'F  ch  I *'rx.LcN.CVM  ivaf  ; _ 

'call  «cT»fve({.*.<;s=f  r,  » i ^s^'Ts  f * ® r s sf#  f _®  r» . » a s s»  i";  1 

ix  1=1  to  »ass?;  . 

Sf_IM0=9! 

Call  ctasnts; 

5Wi  l 

Call  »Lr»cvf  ('-.LSfEPJj re ’ ,srA®  t ,as,!t;  r_pre  , *a$tgi  i 

nc  1*1  rn  iiLTOi  ’ 2 

il.I'XM  i 
CALL  f.TASflSj 
fNO! 


IGTAS.NMS:  PKCT; 

_J+  Gu T ALL_TMC  SnU«CJ/T_Aor f_T  _Na*EJLJC  ThE  ASSERTION  AND  ENTER  THE 

iiPUCIT  QrPPN'HHCY  *ELAT  irv'SHlP  9FTW££f  ASSERTION  A NO  EACH  NAME  • 

only  6XCPPTICN:  IF  ASSsRTfCN  LSES  THC  "REPLACE"  FUNCTION  •/  _ . 

STilR  AG*  _PTo  sASSF"  T.PTR  (II  S 

JP  *D A T A_P  T ; . _ _ . . 

CU^^.gN  T_ASSrP  T^\AMc*C^PTKLe(NAME  (III; 

NAVE  INC*?; 

o 'ye  j*i  To  hk" s;  ' " ~ ’ 3 

0 CNAMF*CnNSCNM(NA-E  INC* '(CO^PCVCX  TS  ( JI  .STCPAGE.PTP  I ; . ...  . _ 

CALL  VL)m&wF(  \A"f  !hC,  *CCMPC*fN  TS  ( J I , S T C P AC  F_  P T * , S T.  I NO  ,ONAME  , 

TRY.ENTPP_ff-l.MdTQ  I V ) ; __  

c / * • 7*  y.e\*7  E’“  ~ I N.V  A TP  I X • CETURNS  'l*  IF  THERF  ShCULC  PE  SUCH  AN 

A T T E *P  f « y J 

C IF  TPV.FNTEP.IN.VATR IX  THEN 

DC  * . _ 

/u  l F ASSrPTirv  INVOLVES  ThE  "«FPLACF"  FUNCTION  DON'T  ENTER  ITS 
T A s G F T »N  TMC  AOJAC-MCY  M A TR  IX,  9 EC  AUSE  teat  COULC  CAUSE  a _ 

CYCLE;  TMC  tiyfPLiff"  FUNCTION  ITSELF  WILL  P6KF?CM  ThE 

F L P l A c " '* r N r / S T a C K I v r, _A \ C PF  ANCH._OC...LCCX__FCR.  THE.  "CK5  ICE_EM:PTY?L 

cc.v)f  rrr*i  rc:  fHf  connection*/’  " k 

O IF  FCN*'  3 F P L ACc  1 r.  ST_l\rsi  THEN  ^ 

oc;  10 

<>Q  11*1  T r C1CTIN0  v,hIlE(CICT(  IIK'EMPTZ*  l;  , 

IP  OICM Ill*'ChCICE. EMPTY*  11 

12 

CALL  Er.iJPM  A 7 (DICT  ( ( 1 ) »C»jP°FNT_aS  S£  R T.N  Ave  * AU  TC’^.96  P— COOf  ) * 

r 

/*  f ;TPR  NOCF  vij,Mr?rc  rp  LOCATION  WHEPS  OEPLACE^ENT  SHCULH  GT  IN  THE 

"LAtrL"  TAoLF;  the  LATrL  T A9  L c WILL  6 E CHEC*EC  5Y  THE  CHECLAB  ROUTINE*/  ] 

I I*CIC"rf  (CNA.ve  ) ; 

__I  F II*C.Th=U . 

5c ; 

/*  MINT  I vCi’voLc  TEN  FSS  C 8MfP»/ 

CALL  Pf.VC  V]°  (CNA'*c  T.ASSFP  T_NA*F  ) ; 

R c T IJ  c \ ? 


ENOS 

*LArSLS=  *LAfcE!.S  ♦ IS 

IF  A'l  Afcf-L  S>  *M.Yf_lACfLS  THEN  CALL  SY$FQ° 

( 'FfExnPs.viYtf  LABELS  E XCF  crF0  ' ) ; 

LAELL(fcLA2cl S I*  II; 

0"  '■  ■ ENC';"“‘>*  EKc'  C F "SPPLA tr*  CASF  •/  ~ j 

SLSE  /"  CHFCF  IF  ASS?»T|r,v  USES  A CCNHITICNAL  FUNCTION, 

IN  T“C  CASE  TMAT  CNAmE  IS  TARCFT  TC  ASSF°  t ICN*  j 

A -NO  IF  SO  SET  THg  OFoEnCE^CY  CCCE  TC  SHOW  A CUHClTfCNAL 
OF  OEN0FNCY  */ 

IP  st ^ in- o*i  f.  CPNCfcrN)  then  4 

"C'-lC  PNOP^A  T(  CN  S' E »CUW~F  Evf.ASS'EP  T~  N A.VE  , Cf  NO~OE  P ”COCE  I ; ~ ' " 5 

cL  Si.  /*f  1FMAL  ASSERTION;  fniep  EXPLICIT  CEPFMCFNCY  R FLAT  ICN  SHIP 

IN  MATRIX  lc  SCUQ C F/ TA^rf T NAME  PPTLPNCC  VAL I C A T 6 C */  ‘ 

C CALL  ENOpv  AT  ( OF  AVP  , Cll°P  E\T_  ASS  PPT.N  AMP  .FXPL.OCP.CCOE  I ; 

0 /*  UEPtNUrNCY  HFTwrFv  A^SfRTirN  ANC  CAA^e'hAS  PfEN  ENTERED; 

EITHFR  EXPLICIT  0E°  • CC.NC  CFPENCfNCF.  TP  AllTf.  OFP  */ 
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7*'  in  inn i tT'].m , chfcV  if  •cnahe*  i$~the  ta*gft  n ft  h e- 
ASSreT  tTV  IST.fvn*!)  £ C\A*F  IS  A ‘SUBSET. X*  type  target 
AND  IF  MU  TARGET  FILF  **>>  THAT  THIS 

\t  A SIIFSFT  UFSTPTPTIfM  • THEN  FMfcP  THE  AIJTO.  OEP  EPNCENC Y 
C?*>r  IN  THE  MATRIX  PC  T*rcN  th?  'SUBSET. X*  NAME  a NC  ‘ R * • 

_ WHFk-  IS  THf  J»ECpPr  TH  A T CCF^FSPCNCS  re  T*-6 

t A®  GF  T Flit  NA  MF  • OCM*  M-*£C  TC  WfPPY  APCUT  X IF  IT  IS  A 
SOURCE  FILL.  PECA1ISF  BY  THE  PRECECFNCE  SCHEME  IT  WILL 
f°LLOw  whattvfo  it  r£FCfOS  CN  */ 

if  sr.rrc*i  then 

CHECK. SUPSET.CASE: 

rv**; 

IF  LFNCThVQNAME^  > 7 THEN 

on; 

IP  SU1ST.QCCNA.Mg,  l ,7)  * * SL0  SE  T . • THEN 

DC; 

TPyP.rAa^FItCsrSLPSTPCCNAVE.S); 

J*CICTK(  ILF)  ; 

fr  J*n  THPN  CAl’l  PNETEPRI 

* ( I NC  r h S I S T F N F Y | : St'HSET  OF  FILE  " » | | T PMP.T AR.F I L F | | 
•M  OFSCMOEC,  *•  l. T NC  rCPPE^PrNCIf.G  FUE  CcSCP  I PEC • I 5 
FL5F  /•  V.p  C H c f k ?c  Sl.F  S c T clLF  15  A TSOG~T  PILE  £ IF 
Sr,  FNTP?  CCC5  IF  *ATF!X  pET.pp\  SUdSET  NAME 

ANC  T h E__  C C 3 ° F S **r  F f I NG  SSCC=T  N£«E;  put  must  __ 

Frs’r'fiFc  ‘recnamf  that  ccmpespgncs  tg  filc  •/ 

no; 

If  LFnCTHC  TC  vP.TaP_F  ILF  >><•  ThEN 
IP  SU*»Sf'M  TFmo.YAM.f  lLfc  . I . A ) = ‘CLO.‘  | 

SL  ?STMTr«*P_T  A H_c  ILC*1  •*>  *•*.£*••  7HEN 

map  c.F  II  F _ A v c s S L ? S T c | t c M ° . T a ► _ f ilf  #51/ 

f L JZ  u * k 5 _ r H<:_N/»'c*tF*P_TaP_f7lc; 

FI.  Sc  PA-PwPrL{-.r’i,'F*TF»'P_TAP-FlLF: 
FlLr_ST-TYaF-*F7lPST(PAFP“PlL?.FAME); 

IF  F Ur_ST_TYCr  = « tg*  f 

f p UF.S  T _ T V P = »ST*  C SU*STPITFmp_TAR.FILE»I.M* 

✓ * I • F_.  SUPSCT^FCP  A TAOGET  file  _*/ 

’ then  ’ ■ ' ' 

cn; 

F rLF*'A*>P.c  CT^  rVF*  * Jp*  | I9ACE.FIL5.NAMP  ; 

CAIL  °cT0fVFfS°rCC|  I ‘ F.  * | |P  ItPNAyP.°?TcFVEI  I • I • I I 
fSPTM  | • f.  • | | F ILFNAME.fi-  TRF  VP  , 1 • , 

STAPT , PFC.pt-  FTP  I ; _ 

fF  <UFC.r'T-*’-=  1 THEn'calI  SYSPpm’i 

•FNFXfP:  SLHSFT  p«C  *CT  FNO*»S 

psoc r_p-p ( l ) ; 

RPC*!AMC»CHPTFL  a(  0*>NAME  I III  ; 


14-  IQ 


IF  SU°$7P (TCmP.Ta»^FIL*, l*A)=‘NFN.‘  THEN 
*P  C N amp s • • : F w . • | | * c CN  AM  6 ; 

K»CfCTY( CNA*F ) J 
l.*°!C  T * ( aFCN Ap  F | ; 

Ar»r*/ t ik  ,t  j r Tr.rCP.CCCE; . 

EVD  CHFCY‘.si:r,r£T.CACE 

FNC ; /•  ENr  rf  TRYING  to  F.fTER  rERE.\rENCY  PELATICNSHIP 

AFTvEFN  T*IS  ASSPPTICN  ANC  This  CNAME  */ 
o /•  :«r*  lick  at  next  nv*e  rF  tmis  assffticn  •/ 

- NAME  If.^NAMF  If  Pf.i  c U » ; 

- _ ENG;  /*  PNO  rr  MPpf  F S S I "0  •‘'FpENFFNCY  rF  Ul  NAMES  _T0  THIS. 


362 


-End  GTasn-s: 

l e^.0*- r-- r : ?«l:CI  iNAHC.CCRAS'.H.nEPCCCE  I ; 

/•  r>iis  i>‘-r':s"iiP ? ct.tees  the  rtPENCENCY  selaticnshi°  with 
C'JCt  "O'PCCOE"  BfcTvftN  THE 

J.Iem  ..The  ASScPT  ic.N  'Cl  In  the  1 ACJ*<AT» ; 

If  J«>"f  IS  SOURCE  Vc  ASSET  Ti'ah  THEN  be  l A T I TN  SH I P IS  EPOm’ 
ON  AM  r TG  ClJPAFAY;  IE  ONAE'E  IS  TAPTET  THEN  VICE  VE’SA  •/ 

LCl  yr.A"E  cha»(max_1  ef-_?N»  I vas; 

CCl  vu«  ••  S1:"  fh*f  ( »ax_lfn_na>«b  )v  »p; 

CLL  r,cPC(tH6  ElX^n  HECIll” 

_ OOIC  rviO>!A~EI: 

!C  *»0  Th  a 'I  CALL  P IKCEEB  ION  AH6.CUP  ASN.H  ) ; 

else  0 : 

L * JILT  » (CIJP  aS'e ) : 

IE  L*.)  TH=\  CAM  SySRap  i>e*iexC“:  • I I rup  a SNE  | I • NOT  IN  nicr'li 
IE  i I _ I r:rr«  1 then  /"■  cSAMe  is  a SCUPCE  TC  TEE  ASSERTION  */ 


5-  a 


5 

6 
7 


ttii  4 j j v a r (1  * k 1 s ofccrce: 

=n(); 

oe*jj  bWyA r ; 

IP  I\Cc*p:  P < **C  ( V'  a M C , C UP  a s*!y  ) ; 

CCL  Ci\A.‘fc  C*-A3(»)  WAP,  CLPASN^  CHAP  ( * ) ; 

CC  L_  m i«'»_Or\Pc  ! X CNAC  ( ip  j f*jTT<^_ 

• ( ! fv r r p i. c_t p '» e < s 7 ; Ne'er  tc  kncw~  tc  • » static; 

CCL  '4SG.  jiicc  J A CW.-M4S)  va-'; 

/«  QNA^s  IS  'TT  In  C ICTIC\-*.PY;  I.r.  tiNHFr  INFO  -/ 

iy=*  «•  I \r  \y-\  1 • ••  i?.  iSsr^ricN  -• ! Icu?as*j*  1 1 ; 

IF  bT_1»,r)*0  THFN  /*  ONAVC  fS  AN  'JNfF F ffJCC  SCU?CC  TO  Th£ 
ASS-°  T I C'!_  */ 

Call  »'«r  f«S0_iTocc  i * jf'C??*/ J fM3C_SLFF  I x) ; 

CLSF  /«  CNAMC  I $ AN  i I \ ? F F I c c target  CF  ASSERTION  */ 

CALL  PK5TE&P  (ySO^P-.FTIXl  I *LS=  * I |1<G_$UFF  t ; 

EM)  PI*:CEP»<;  _ __ 

-fnc  cnfxcf; 


J 


•PRC  CrSS  1 *\s  r,  *ACP<I.N*F\M'?PFl  . S**  f 2 , 72,  l ) • ) ; 

6NHF-*Ei:  /•  FN1B’  ALL  THg  h l EP  APCH  t C AL  P PAL  AT  I CNSF*  I P S INTO 

THE  ACJACE^CY  MATRIX  • AO JM AT  • */ 

TCCL  HAX.LF  N.O-sAmt  FfXEOj  . 

tCCL  <*  AX  % — Tn  T_F  ILES  PUEC; 

COCL  M A X ,LF  N _ NAMF  PfUfP  *, 

COCL  .Mix7_0£ TOffis  PJXcC: 

• CCL  »- 1 ccj_(\4P.jr_CCOF  F [XFC ; _ 

tnct  Hrr^.rj'jTPHT.cocF-  r ixfo; 

t?iAX_Lc>  _QNA*C»32  ; . ... ..  

j^aa*  _rr  r_t- 1 l es * i 2 ; 

f*AX_LF\_\vjF?l05 ' 

^MAX«.^«T»T*»S*200S 

4Mie»_i\pyTj:one*i5  

4hl  6-„'.LrP'lT.C^L'F»2  ; 

Ui.CLUOc  INCLIS.  (CSFCIPIS  . . ..  _ . 


CCL  *OJ*AT( nICTlMn,0ICT!\C»F  IXFP  SIN  C T L gxT; 

/ *ALC  C'CY  ALL'ICAT  E*  py  SET  ge\  •/ 

CCL  TIC  TIN.}  eixr"  <•  IN  FXT; 

JCL  S1~*'T  oi.fMTrF  ? x T ; 

CCL  ( P £*F  , TON  A*  F J r>  (*5  (•*  AX_L  r*  _CNA*F  IVAP  ; 

OCL  c "fnT7^|MAXH_*'t  to’TbSi’pcTnTE?  f xT  ; 

OCL  (FlLfVA*-C»P=f  fKrY\A^e)r>Ak(  v£X_LGN_NAP6)  S 

CCL  CH.J  TF'L  6 ?*IT»Y  f CH.V»  ( • | )t  CTIJFnSCCF  AP  ( X_L5N_CNA*i  )VAW  ) $ 

CCL  Mtr.S.T^TVPF  CHAO(^)  STATIC; 

CCL  h l L !-  T Y •"*  5 C w A4-  (*  a x_Lr"‘_AA,/p)  STATIC  I M T ( • I F l L E • ) : 

CCL  -.PTNTYO*:  Ch.v-  J’-.-.x  J =-:~f  fi.*r  I S TAT  rc  IN  I T ( • f opr\ t | . 

"CCL  c cC  ' Tyac'  '>'■?  <NAx_l  >\_‘  ' VC  ) "STf  T IC  IMT  (,i«5CD,l5 
CCL  I rPTTYPE  CW4M‘'lX.lfs.^vr)  STATIC  IN  l T ( MhS^T  • t ; 

CCL  L T Y P r Ch*u  ('*ax-l‘v.aav::  ) STAT  iC  I n 1 T ( • lra ° • I ; 

L'C  L FLf>  T YftC  CMA  - < v AX  _l  ? £ v r ) ST  AT  ! C I N | T ( • f FLD  •); 

CCL  tMPFT-T  YAC  0.*./v.*x_  iF.N.A/vf)  STATIC  I A 1 T ( • IA  $ SB  B T • ) ; 

OCL  ' CT  CHAP  111  IMT|'*.'|  STatjo; 

CCL  l*CT  SIaTIC""IN(T('.»|; 

OCL  AiN'J  CH*'  III  I * * f T ( • C • ) STATIC; 

CCL  c*  I*  Ir  ('1*1  STATIC; 

i,CL  FINEST  S:.r-Y  IphA*  (»ax_l  £N_\ apC  I )PFTljaNS(C>-A*  ( 21  ) ; 

CCL  CICT"  pnTPY  ((>.*:>  ( - |VA*>7  cF  Tl.P  NS  I F 1 XFO  p I N I : 

CCL  Pa.-F^r  :r.r-'Y<  Pr  t\ T -y  iJ-CTjjzt*!. (ChA?  ( '4X_L  CN_N  A*'£  | } ; 

rCu  ^ F !LCr'wCS  F~|yFr»  |*  I f?  * 

CCL  F lLr_Nr s^ojo (max »_ Tr f _r fL cs  I PCfAT?fi; 

/“  L*E  r c.-.CH  F l L c «=  -r°n!’T  r s F I \ ! T I T N STRAPS  = N To y •/ 

CALL  Pi:Toevr(FIlFTYor||fW||prp^TYPE,'»,STAPT,rILe_CeF.PTaf 
<F  fLfCEFS  1 ; 

Cu_  1^ i Tr-  *c  , L f rr-P$  : 

/*  F ;p  **  ap  m f ft "c'  pp  ‘oforr  T CFMA  I T ICN  * •/  * 

STPOACc.0  TR  *F ILF.OFF^PTc ( ( ) ; 

F ILFNA^FsN AMC (1)7 
-£CNA Ac*NAmc ( 7 ) ; 

S revi:  AMF^NA^r  ( 3 j ; 

<r-Y\.V^cs*  AMF  ( /,  ) ; 

F '(LC.SlT.T  *Pf  sF  Ii  cs  f(  f'I  LEN>mM  *.  /•  CURPS'lT  FILE  IS  SET*  TO 

» 7 Srij»CFI,  *TC,»  ( TAP  ft  s 7 ) Co  'ST'  MOTH)  •/ 

CALI  SNT^H  I f>9_  ACJ  I F u sN  AM*  VPECNAMF  ) s 

CALL  EMT^NFC.AC J(  FILFNA^‘=,STC3NAV6|; 

FNO; 


Va  4r 


/ 
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lc.'iT_Hlc'_AOj:  PKnC(Pfi9.CCSrF''OANT  » QFCU^SlVf: 

/•THIS  PPOC  FnT£?5'  ThE'hl  psa/chICA'i  PEL  ATICf-SHlP  IF  TWEEN  "'PARENT # 

ka/6  a,p  • o»:sccNrAM*  in  t»-e  apjacekcy  *atsix*/ 

/*  THE  TYPE  UF  PFl  ATICNS^tP  IS  A<  F'-LLCv.S: 

i«  h i F r 0 c * < l c 4 l pfl  at  tr.'i^MP  ir  thf  t wr  itfvs  a.<e  in  a spu«CE 
file,  v c p 6 l at  i rrj  gccc  sr.!*  p4"f^7  ’ r cfsfcncant: 

Z~h  j E'-  A^Qf  CAL  Pf  l ~T  r C.\  S u l ° If  T h c T wr  f TE*S  a^s  th  a TARGET  file 
- ►rU  R*rLAT  lr>‘  f,e=P  "?VC"  CrSCS*.PAN  T TP  PARF’jf. 

IF  the  C'l°°  t N T o a = FNT  FILE  IP  *PTh  a SUf^C*!  A N P TARGET  file#  Th^n 
Twf  1 The  TwO  I T e S APE  patFIxEl'  WITH  • C L C * ANC  »Ncw  • ANG  THE 
h t L A T I w '•  IS  F'-'TEwcn  l.\  ?PTH  GlFFCTfPNS.  WITH  T Y P F l ANP  2 
“•cS^rCT  IVcLY*/ 

*CC  l j>  a * a o p p AP_rtn  fixes: 

*max«_  ’.^rc  ap*Jflc*so; 

DCL  RP  T_PAF  _N.\MF  CHAP  (VAX_LEN_NA*F  ) ; 

CCL  *n  ET.iJ^SC.STp  CHAP  ( VA  ) ~VAP; 

ccc  fa;  Cha^Tm  ; 

CCl  DtiCrN^ANT  CHAOC-'J; 

CCL  ( F -.NAV5  ,(5PNA>F  I r>A.k_('i/X-LEN.CrA^F)VAP: 

CCt  CL-  ’P  wf.SF  o r f \ Y f a ; 

/•fnE  G':i3r*T  s 1 1 3 A P.  t F\TPY  IS  pCINTPH  TC  r»  Y • C IJK  » F N T _S  F ' * / 

0C-  OsSC.  >TV  pinX  »-.*.PpFA‘>_F|.n  I PCIMTS; 

JCl  «3tSC_0f^  cix[3  Al\; 


CCL  iY  POfATF.®; 

DCL  I » . J.lAST_QF$C_»rS ) FtXFC  Plv; 

< r.r  Lin  i vgl  i *•  (p.any  i ; 

/•r.jf  I..piv:.9[,  This  P^r.FjUPF  ENTERS  THE  p f l A T I PNSm  I PS  PETwFFN 
= aCm  lFf.f.Pr!)ANT  AN*Q  | T S SUCCFSSIVF  FCSCFNPAMS  ay  CALLIN'".  Vl  ITSELF 
►CC Jfc SI V~LV-/  ‘ 

CALL  e.NhFM\T;  1 

P.  F T _ P A - _ f A M p = * 1.  p ' | | F II  C N a v F ; /*  s F T PAPFNr  NAME  •/ 

/*  arr(.fcvf  STf^Ar.h  cf'TC  Y '«*  h F p E I!F  SC.  FN  CANT  ITSELF  IS  Cf-FINEO  «/ 

a E r _ r c'jF^sta  *(jc  sr  cr.CA'  7 1 I an.ci  | p f t^oas^na.mf  ; 8 

__  call  *c  re f VC(F  r T.Pt  sr_ S tp 

, • • ,STAF  T#i)rSC.FTS  *«r.6SC.PTP  ) J 
/•*  FX'EFT  7 STTh^PF  f-Ttpicc  wjTh  CESCF'PANT  \6.*'F:  Cf.E  KHpoc 
MF\rIPNC*?  |N  PAP.FMT  DFF|\|T[C\  ANC  CNF  * h F P F QF  SCFnO  anT 
I T b c L E is  GFP  IMPC  */ 

IF  *Cfc$r.^PT->  *0  IH6^  9 

nr ; 

CALl'os  HfcFoVfog  ) 5 " -----  ^ 

F 8 tupn; 

E -*0 ; 


4 
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CURRENT. SF,  

ST  JRAGE.PTR-OFSC.PTR t i | ; 

IF  A M Ml>-.«Rr  SC  F NOANT  THEN 

cc: 

IF  wOFSC.PTQ  < 2__  T H E N _ 

00; 

_ C All  PS  HO  8FP  (001.5 

RETURN; 

ENO ; 


IF  YCESC.PTR  >2  THEN 

or;.  

call  p-»hpepp  ( ipi  ; 

RETURN;  _ 

En-C; 

CUkRENT^SE  , 

STO-  AC?.PTR«CESC.PtR  (*2  j ; 

I F NA^eFl J-sf ESC FKOANT  THFN  CALL  SYSFPfl (DESCENDANT II • U NOEF'J 

cM) ; 

OP*1"*  A T A— P T ; _ 

IF  ANY.S TMT. TYPE- * FLO  • THEN  " ~ ; 

F-tJ.5 

CO; 

IF  ANY_S  TMT  . TYt>Es  »GRP  • | ANY.STHT  .TYPE*  ‘PECO*  I 

ANY.S TMT . TYPr» '«PTN«  THEN 

cc; 

LAST.PSSC.PnSs^KEYS  - 2;  /»  L/*ST  TFSCFNCANT  NAME  IS  IN 

JLnJJTjn\.-J<e^^.Ce  -LHi_CuPP-.EM_SrCPACE  E:\TPY  .*/_ 

CP  Is?  TP  L AST.CF<C_PCS  ; 

ST  )OAr.r_Ptc  «CL0:>ENT.SF; 

CALL  evt^HIER^ACJINAHEI  l)  ,NAy6( n I ; 

fcNo; 

E \*o ; 

E L St*  C *•  L L SYSc^CCESCE  10/  II  L11_1U  CC  A L_  T Y P E 1 ) l 

CMP; 

IPFHf  c-  i':  p«CC(U>:OEF.p°_^yp  IC)  ; 

JCL  UfPfF^w^AyoYr.  "Ffxrr  pin; 

OCL  HSr.lCsil  CMAO(25»  V *• 0 I ► I T < • PfSSINC-'t 
1 gescp ;:ro  *cff  than  cnce*i; 

CC.L.JiSC-.TYo.=_f0U  L.C»'-C  I !'•).  Vi?  j*.  in  . jvLCMrtc  TcNESS*  , 

• I*  CCNSI  5 TFNCY  • ) ; 

CALL  P ,CTEt'*M  • I • I lySG.TvpCPJf  rFF_CP..A.MP  !C)  I I ' ) : G'-OUP  HP  FIELD  1 
nESCcfiPAf  ■*'||#  r.  • I |pap  1 1 •'SG(uNCFF.cH.Ay»iiGn  : 

RETURN; 


END  P^HPcOf  ; 

IENnK-yaT:  P^rC; 

/*.;jal:ey  pjofT  an-c  cescf.vcaatv 

IF  PARs  F ILeVA*>F  THEN 

og: 

""oCnm^E  «C“6T*f«rL  E (F  ILCNA«C  I ; 

DONATE  .rMDfi*  LP  C5  FCNA.VF  ) ; 

cno; 

else 

DO; 

IF  PAJ.«RfCNAME  T K f N P CT.  A»‘ ^ *C  ►- P TP  L ° ( c A P ) : /•  ° c C H A M F S ANO  RPTN  NAMES 

P t **  A l"f.  UN  Dual  IFf  EC  SlFCF  T H-  Y p £ UNIQUE  •/  * 

CL  S£  /•  PuAL  IFY  ry-r  ''AFFM  fPPLP  FA*P  */ 

P CNa  '<F  *r  MP  Tu  Lti(PAF7\  rfS’Tt  AC  ?.pffc  II  | I CPI  I t ChP T?t 1 ( P6P I ; 

/•  w'JALIFv  r f- t t)rSC“fcOAVT  \a*?i  •/ 

OCNAN?*f HPfi L n ( PARENT  CST«>  ACE.PTP ) I | ICCT | |CHPT®L  0 (DESCENDANT ) ; 

END; 


-y  t vti-jmtv 


IF  1=0  T-*FN.  CAll.  SYS^PP  ( 1 1-  IL£NM  • Hrcn_Tfcyp_ri.'lAME  I I 

• »rr  r.*i  r f cr  « i ; 

Ac.j'  at  ( [ ♦j)  = FfL--STr.*?-ccrf: 

NFw_  rcw^.ft*  A’-  w . » I | T f R P _ F L N A N E ; 

laCIC^I  " 

"if  [=0  thf*:  c ai  l” sysfc '» < * f ln  .\fc f • | I N FV’_T  E v P_EL.N£ME  II 
' hr  T [*j  CIC  T • ) I 

anj;-AT<  i . j i * r ii.e  STc**.cr.CF : 

Enos 

CLSt  /*  FILG  is  EITHER  SCi^CE  C P TARGET  "/ 


[ = Cl  CT  (/ 1 tcmp-f  i.na.wE  I : 

If  I s 0 ThPN  C;.il  SYSF30(  •FLNWE  1 | J T F y P_  F IN  A«  G | J • NOT  1*4  C IT  T • ) ; 
tr.jKAT  t ! , J)  = F iLF.STf  P.cr  nL  : 

6 NO : 

c txn  t\ r_* : 

- E NO  G.V*,<f  Fi.j ... ..  


l F F lit. S.T. TYP6= ‘SM*  |F  ILF.S.T.T tP6  = • TG • THE  N 

OC;  _ 

i*m CT#< PCNANF ) : 

If  l*C  THEN’  CALL  SYSE  op  (PONAME  I I ' NOT  IN  CICT»JS 
J*GlCT«<nCNAME|  ; 

[F  _J*0  THEN  G A U SYSE^o  (CCNA»£  I l_|_  NC  T _J_\_  C I C T • I 5 

EMC? 

IF  F lLC.b_T_TY°r  * 'SO  * THEN 
/•CUPACMT  c!LE',Af'e  IS  A SOURCE  FILE*/' 

AUJ-«AU  I , J|*hlFR_!NPUT_CnCES 

cLSc  U FILF^S.T^jypr  ,f TT  • Tf  £\ 

AU  A T ( j , l )=HER.CLTPt)T_crCE; 

ELSE  IFF  l L c_ S_ T ~*T Y p F * •"$ T * THEN 

no ; /«*CUk«FMr  riLF  rs  pcth  anc  output  file*/ 

l *LICT*(  "A.  - • I I PC.'.A'*F  ) ; 

l r 1*0  Th^n  gall  SYSFCR  ( »GLC.  ' | I PCNAfE  | | • N G T IN  C I C T • ) ; 
j = QIC  T i(  * CL0 • * I I OCA a-«  I ; 

IF  J*C  TmRn  CAt!  SYSFn’M  »CLr  . • | I rCNAHC^LI  NCT  IN  CICTMS 

ajj^ati  i;jjrH|Ci>_if  pt»T.rcre;  " 

I*CiCT/«<  • N'E’.'  . * I I PGVA  VF  ) ; 

IF  1*0  TMfN  CALL  SYSCPP  I *f  FW.  • | I PCNAHF | | • NC  T JN  0 I C T • I ; 
J*CIoT4 ( 'Mew.  • | | PC\A*c  ) ; 

if  j*o  then  call  s y s e c * ( ' * e w • • i | ccn a m e 1 1 • nct  in  cict'i; 

- ^ J *AT ( J « M*Hirc_CLTQUT.Cf  C6: 

E.D; 

EL-iC  C».LL  Sysf-jr  (HLE'  a^f  I I • NCT  S / T • > : 

06 NO  FNmkmAT; 

-ENl  E.\T_hIcp_  A^J.* 

l tf.T.'iJ_Ar  ( cl\A-F  , STN.AVC  ) ; 

/•THIS  P°  C r *•  T F ? S T Hc  ° " L .*  T I C**«  SH  I P oerwrcN  a F { L FN  A v C (FLNA*E) 
tn’J ” I rs  r j-iissw-*  me  sfr-'-AG!  ‘ ''FTILV  N A v £ (STNA^cj  ANC  ENTERS  I T 
in  the  acjagpncy  ••atpix  as  pelaticnshif  typ*  t •/ 

/UGl  F lL‘r.STro-c,'r'F  FIXEP; 

- F I L r _ j r-J.Gf  Oc  *n  : 

GCc  ( Fln  u’T  , STf  *MEI  ^HAOI*); 

CCL  ( T‘-  ',P_FLN  A*  E__,PL_^.Tcv^-FLN_A^^*NC_w-.TFMp-eLNAH€  I _CHAr 
( **.  a'^E  f vi3; 

OCL  ( l . J ) F ! Y G n 1’|m; 
r E <P_f  f'A"'  ■CHPTR  La  ( FI  «|A^3  ) ; 
if  <r\A.-f=*  • ri-cf  pfturn; 

J*UICT*«GhPTOLi».  (STNAvf  I | ; 

I h J=0  ImFNCAU  SYSFI.P  f • STf_U  age  N.,#  • I I STNA^E  | | ' *.Z  T IN  C IC  T • ) S 
ir  r i luJc_t- rv-f  =*$n  tmc-j  /*  filt  is  »cth  sg'j«>cc  f.  ta^gct  •/ 

dc; 

^LC_  r = MO_PL>A*,(-s,rL0#'  I I TF°p_PlnahF; 

[=CtC^I  .,LO-TCfc!P-F|  NAMg  ) ; 


X-  r '4 


♦ Pf- 1 jC  F S S ( * *4  S T , A f.  7 C #N*PN  PT°FL  ' l ; 
fcNR  TP  E L s PhCC  ; 

/•This  PtiCF.C'JCF  t»'TEFS  Fftf>  PC(NT?e  N A K F TC  POINT  TO  ITS  _ 
CCRAesPC\*oi*if,  f cc  n u n«*  adjacency  matrix*/ 

*?ncL  n XJ  r- o_na "G  _f  i xcn_; 

;ccl  yAx^ir r.”^UAi..\~flv?  fixcc; 

<OCL  P7«Oc  lZC-PF  FIXED; 

•5DCL  ra  .r.A^FS  FlXECJ 

Sk/.a.lE  *_na*'6«10;  . ..  . „ . 

^'aa*_^ci\*t  pp_>iAM?s  *12 ; 

VIAX.Lcf  _;HAt._f.A'«F  _0  2j 

•fcr^wirL^r^Tg ,«, 

K l oCL'J^U  P-!C  L > °f  Dr*  t C T ) ; 

uCl  AuJ.V.M  JlCT  ! NO*  etc  T K,p>  MX  EC  "IN  F X T CTL; 

OCl  U 1C  T # **!T:v  ( Cm  A*<  (•  J VAR  »tc  TURNS!  F (XcC  DIN); 

OCL  Ff.  ,.\*'r  rHi-  (•«  AX_t  a ve  ) var; 

CCL  -C  - F r ►;  * * c Ch.*./  ( v AX_l  CM^CU  Al_\dwf  l„VAP  ; . 

JCl  START  p° ! n t - o c x t j 

✓ » "|\|i  ALL  PCi'TE0  N A"  c S (N  TF-e  CICTCAiPY;  I.c.  VA^CS  ^GINNING  wITH 
'>,I,!TC«.'  •/ 

DO  1*1  TC  nirri**C  V.-Ml*  ( c 1 c r C r )<*cc»  I ; 

I F L c «GTM( Die T ( ! ) *>H  then 

_ jf  sms  to i c r i r i , i .rne* _ 

'"bo; 

/*  t\kf  r».iPRF*'T  ctcnc^ipv  rvrpy  rfcinning  *ith  • pg  fntfp • • 

AND  £ X T r ACT  T Hf  ^CCCRC  NA^e  WHlCh  FCILO^S*.  rwc  RECORD  NAMF 
r.w  Pf  C'jALfF[cr.  .affp  i ROFFfXcD  •CLO.*  0°  * N £ W , ' •/ 

qw  F<V:  = Sti'.STM  D f CT  ( I ),<?); 

J*r !C r » f ;ofC‘ a vc  ) ; . 

T-  JS:  1>fn-  C'Ul  SYSFos  (OP  cCNAMc  I I ' NC  T COCO  PTRNV'I; 
A}JM&T ( I ,jl*Rrc_rf L.CCC6; 

t NO ; 

£‘H ; . _ ........ 

OC.NO  cNPTPcl; 


•Prfucsss  < •*•* #x, sa«i 2» 7*t l > #*«Firvc*T  tps* • 1 5 

FluwuPT:  Pf-OC; 

/•  THIS  P*jCcO'J&£  T A<  £S  TKE  CPOTU  VFCTCR  AAP  E[\C$  THE  (.OCA  T ICN  OF 
•OL  ?NO*  Pft|®S.  •/ 

_/•  k fpl  a t i,\c  Qg^ijos  rn  rye  »Mcrri*  lanchace  will  kccutpe  that 

LCPPS  P*  '.t^PATfo.  Tw'e s c v ay  -4 F N^jfcr  thei^  QANr.ES 

kl  s t 36  j;scrvc-£n.  rr  make  sufc  t*- •. t this  keeting  tak«s  place 

oo'.PC^LY  AN  r rn*.  r STATEMENTS  NOT  CEP0*LIKC  PN  THE  IPC?  APE  *CT  jN  lT^ 

MANOfc  rnf  liPQCC  v CC  T ')  p M r L L «?r  EEAExANCcr.  CAPE  HLSr  Pf  F *c  9C I $60 
SC  A > .\CT  TO  UPS=T  ANY  PPECEPF.NCE  RtlATlCNE,  •/ 

C/*  k A T 0 /%  N A L Ofc('C  ErU-  £ S . •/ 

"7*  whc*»6  “oc t,r«',fAcs  hcn  fap  a nccc  iN’rV-t  cppep  vector  has  *ffn 

DISPLACED  /.(-rV  VO^fS  have  trf\  ,'CvFO  OuTSlPC  NANCES  Ce  OC  ILCPS.  •/ 

GCL  -HC^t  ENTRY  C F l X.  c C ilN.  <-)  FIXCC  -|f<#  (*)  MxFO  PIN#  FlXfO  PIN, 

F : x 6 n PI‘1)  f>cTL^s(f  IXI-C  P I * | ; 

/•  EEC  TAP  TAKES  A NT  *F  Mj"rF"  A\C  A 'prcfACF'  *AM0  A\0  P £ TU°N$  A 
_ PTJIf.TCP  re  j*  LPKrO  LIST  rjr  S TE  L'P  Tl1  p » L f k r • Mp  v E.*  c L 0 • . ThI< 

" LI  i r'CjNTArs  thF  V/.veVcF  * IlF’S  a*r.  Rfr  . :»CS  >*■  I C?  CFVTajm  fields 

wcc  a > taocets  or  the  assf£tio\.  a filf  cft  feccfp  is  incliicfc 

CM.Y  IF  T b*  Fn:  TT  CONTAINS  IS  '‘PCIFlEr  ay  fhr  c IV6M  •fraFL  CM*  nA«F. 

• / 

CCL  = cC T A?  FMTCy  PMijBNS  (PTR): 

7LU  b jcHJ  a^E^LEN  FlXfC; 

? F A C b_  ’ t •*  M u Jl r ’ J - l 3 I* 

0/«  | A T = <•*,  AL  PS':Cr  HiP  F S ?£*'(  Vc  T ► F < c ''F  C l AF  A T I C*‘ S FC»  OP  T CC*.  •/ 

OCL  FCi'SACH  r:T-Y(F  fxFO  “I*',  FJyEr  ((A)  r *■  T I c \*$  ( P T C ) ; ■««»«»«• 

CCl  SiCOVvP  F\ T 8 Y I ( * | PIXE''  » T N . FI*CC  S f N ) PE  Tlj&N  < ( ? I T ( 1 1 ) ; ••••*•* 


CCL  \Ew_PCS  c T J y QrTiwNS  (r  i>  crt  p»m  15)1; 
uCl  jai*  c*.  t-y  f'f  tiipn<  ( p t r ( i » i ; 

CCL  A.'uNO  cNT-  Y r rijg**s  ( I T C 1)1; 

G/*  F X T = - .AL  V A • f A a L ► S • •/ 

/•  K.iit-IAT  IS  T'‘r  PATH  ^ M CI  X F*^P  _A  LI.  NCTF  $ . •/  __ 

3CL  0 5 'Ju* ’ F r I x F H F.’lN; 

G‘Cl  patmmat  («,“)  9 f T ( i ) C T I.  CXT; 

4li.CLGOfe  |.\f.U  C inniCT  ) ; 

CCL  C FIXFO  PfN  FXT  CTL5 

/■*  »uLrA6'  A.*.o  'C‘:f;TAP*  A P c A»®  ays  USCT  TC  CCMMHMC\TE  Tbb  LOCATION 

ljf  th£__» cn * a*  r • f ° t a r c m r •;  r s • thcy  b^ i : t bf  si.pscfipts  of 

of  [bc"e  [rjT  A*1''  LAFf“c  V.  0W=*:TS  rf  f f ? r*rfe  VJPTrp  J kj  T b F LC^P. 

A 00 1 TIOr.ALL  Y • 0^  T A**  1 CONTAINS  Tbf  #rrt>c/io»  f CS60  IN  THE  LOOP. 
UfcFL-e  k£  Tijsm  THOSE  LISTS  A®E  SPiTEn  I*.  TP  A?CF\CIrO  0°CfcP 
TV  | S iKSUPfc*  THAT  as  The  CC^FP  vccrop  IS  SOUNEC  T h * S € LISTS  CAN 
»e  PFZCEO  INTO  tT  CATHTP  TMAf;  0>CC^rC  CC,#fl'TC^y  at  ?aCh  MOOF  • •/ 


I I ms? 

1 T i ft  ft  ft  f 
ft  tftftftft 


-y  r 
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-/•  hit  CHECK  fcV f * Y ELc^EM  IK  The  CBCE«  VECTCP,  •/ 
*locp$*j; 

SlAk  T.PTH*nULL ; 

CHK_cajtw:  nr  vec.fntrv** i to  cicmncs 

.% £{je**(.°r'5ty  CVEC. Entry  « ) ; 


/»  uYLY  ASSC-P  TICKS  Afc  Ti»  cf  CHECKFC.  */ 

VES.ASS'is  IF  ncrvPF  (\crcir  |*  • dSTC*  Then  CP; 

EaCm.p  to  *fc*F  AChCNOCE*  ,VEC.EnTry«); 

IF  paCh.pTB-.*  NLIL  THEN  CC; 

/*  we  *usr  gf negate  a cc  £ko  ftp  this  forfach  name.  •/ 

/•  C|Kn  TmE  NCOF  FARTHEST  HCWN  IN  THP  C?CEP 
VrCTl  w WHICH' IS  C E PENCE* T O TH  IS  NCCE.  TMS  W ILL  96 
f Nc  LAST  NCOc  fN  Thc  LCCF.  • / 

no  last.oeps'mct  inc  t:  i °y  -i  wh? lp  i.-pathpat  in*cce». 

C« HE P(L A ST.CE^)  I I ; 

EN’0;~ 

/•  ^Tinc-N1  the  ^ t i r \ re  t »- f crffp  v^ct c*  cetween 

rnrs'  N?CF  A*:r  I r'S  fESOENOENT  i *•  f G rwr  G^Cup s s~ 

ThjSt  IN  the  LfCP  A N C THCSE  CUTSICE.  •/ 

*NCT*C; 

» yfs* i : 

yfs.ofpi  i mvpc.fvtr  y*  ; 

SiVE.CPCf-'T.DF'M  l)*KrC£*; 

" partTt "irV scr'"oAor^p.c’r"cP«v>c.5NTBv*» f tc  iastIpep; 

/«  IS  T w T S 'ICCE  OEFE^Er  r PN  T *-  f assertion?  IF  $0 

cr  rs  in  tm«  lcc*.  save  its  lccamcn  avc  value-  •/ 

CEP_NCrF*r &rfF  (CART.\(.Cr*l  ; 

IF  PlT^w.*TI'Trf  * , f*F  P_NCr F ) THFN  on; 

* yc  S- ‘'Ye  5 » 2 ; 

’ ( * ye  s )*p  a pr>  COE  * ; 


3 

4 


YE  ‘ J'Fi 

SAVr.C.Fl  6?.0fcPl  » YES  )*CEP_N':OE  ; 

PNC; 

ELSE  or; 

» f * p T * *NC  T ♦ l ; 

_NC_T.r- P (» • r T ) »PAP  T_\rCE  * 


ehd; 

£*:»)  ®af  Tf  T 1C**; 

/V  TFST  thf  NFW  LCPP  r C?  ILLCGAL  CVF-LAPS  with  old 
LOOPS.  •/ 

if  -.oacovef  iyc?. cfp , «yesi  then  cr; 

/•  ALL  r . <.  ►rvF  T E \crrs.  •/ 

/«“  THE  "r.r.ES  NC  r OTPcNOEnT  *LST  CG~Flf'Sf'.  •/ 

m move**;  tc;  yn^t; 

OPCE°  I*GVR»  ♦VcC.FNTPY»-l  » *c«>Cco  (NOTICE®  I 
V0V€*T ) ; 

ENT; 

DC  ‘-*0 VF  * * l TP.  *YPS; 


CPOE®  ( MC  VF*  ♦VEf.ENTPY*  **NC  r-  1 ) *S  AVE.CPOFR.OEP  ( 

move  *7  ; 

ENO; 

/*  wE  FAVF  *nVpC  NCCES  SC  wF  *LST  UPCATe  any  ALTERED 
no  F\n  p a i p s * •/ 

/*r nee*  f«f  LfN«cO  LIST.  •/  

"tiL!  ST.P 1^ ■start *^T3; 

cr  ^»-iLr  ( t_l  r st“ptc-.«nlll)  ; 

DC.EN0.PT0* T.L IS  r.p TP  ; 

C ISP*WHEPS  Cor.LCC  .NCT.r-EP#  YES. CEP,  *NOTt«YES>; 

or.Lrc*nr_LCC»r:  I sp; 

OND_LnC*F\C.LCC+n ISP;  _ 

t"l  ! ST.PT *ney  T.CC_ ENO; 

Ffc,0; 

/•  SAVE  TH"  IC.OaTICTS  of  the  CC  A\n  ENC.  •/ 
y c s.o e p c i ) svrc.PM’T*  > mnct  ; 


^ T .'T| 


0 


371 


thus  we  op  not  neet  tc  pass  thrpugh  the  rpnee  vector 
twice.  •/ 

ir  < (f;rne_TYPE*  «cccn»  > i (ntc6.tvpp» »pptn*  ) i then  oo; 

IF  *:ve.ou T THEN  cc; 

/•  $AVf  T|.r  LC  CAT  fPK  In  •CRr*FR*  OF  Thf  N'PCE  S TO 


14 


rtf  *nveo.  •/ 

• •'PvFC«*MrVEf>I  ; 

MOVE. NODE ( PVCVf O )*VF C.ENTRV* ; 

ENCi 


ENO ; 
ELSE 
IF 


MCC. TYPE*  »F ILF • | NT  OF. T Y PE* • 0 g P T • 

IF  vr>v£_nijT  TI-EM  CP: 

uneven *#*c vec»  i : 

MOV  FENC'D  F ( *»vCVf  C ) *VEC_EN  TPVU  ; 

ENp; 


THEN  co; 


14 


FM05 


16 


E*:C; 

cNH  i /•  E'iO  pc  | T?o  A T I Ofl  THROUGH  ICC*.  */ 

/•  »o’A  CHcC  < TC  SEE  IF  NUPFS  APE  MCVEC.  */ 

IF  4 **  CV  F C >0  THEN  CP; 

/*  ^nvc  thc  n-'Ofe.  */ 

/*  » N_c  X T _LC C • I V C T C A T E S T H 2 P C S I TICS  AVAILABLE  FCP_  THf 

ncc*  ~r*  nTe’UcV.  •/' 

\r*7_L',C  *CC_t°C  5 

Cl  vFc.cv T°Yiscr_Lr.c  tp  eno.icc; 

/“  • CHECKS  tc  SEE  IF  'VEC.FNTOYV*  is  A«CNO 

the  \COcS  tc  rc  HPVFp.  •/ 
f f-  \f*r*  C-  ThFV  OP; 

■ / * SAVc“f^E  NC'CFS  ~Tr~  56 " MCV6C  •/” 

• ►•p.vFr..nFOcPs*.»,rvcr.r‘»rFP»i: 

*0  Vc  O.Pf-  CFW  I »*Pyf  C.CPGCP  I*CPOEP  ( vEC. Entry  * ) ; 

f *;P  • 

ELSE  00;’" 

_ /*  *0 Vf  NICE  u°.  •/  

“PSRCQ (NvX T_LrC I *CPOgP ( VSC.ENTFV 4 ) ; 

NFxf_LCC*NE XT. CPC#  t ; 

END; 

Enp  ; 

/*  INSERT  THE  MCV-p  NCPES.  •/ 

CO  J*I  rP  »vnv£p; 

~rp(.Cp  (Nrxr^icc  »J-l  » 5.vPVCC.CPCFP  I Jl  ; 

6NC ; 

/«  CHANTF  TH?  ENP  LOCATION  THE  START  IS  o.  K,  •/ 

FNC.L^C  »E\,r.LCC-y.MrvCC  ; 

/■»  HAVF  vr>VcC*HCOr S - UFCATK  CC  ENC  ICCaTITNS.  •/ 

S.lVf_;>T3=0n_s* -O.PTP  ; 

,j^_E*!n.°  T?*  S TAR  T_»'T>  ; 

CF  li?C.CNO.or®-**N,Ul  L ) ; 

/*  Wc  *L‘FT  NOT  UPCATF  thc  cup  fen  t l^op  tvuCE.  */ 

IF  D^.f  *;P.O  T?i-.*S  A V?.P  TP  THEN  CC  ; 

/*  •urw.PP.S*  CCrtPMTFS  AN v C I SPL  ACPRFNT  CAUSED  5Y  THE 

SHIFT  pc  N C P c S._  */  _ _ 

U j.Lr C r r«r'.L CC  ^UF  rt_  pc  s ( CP.l  CC  ) ; * ~ 

SNP_irC*t  NP.I  CC^MF W.PCS I FNC.ICC I : 

END; 

DP.FMD_PTRsNFXT_CC.cNC ; 

cv,p; 

_ CC.FNO.pto  »s  AVg_PTP  ; 

s.NC ; 

/*  F»Z  c Tm=  ST^PACF  ASSOCIATED  U I Th  the  LIST  OF  TARGETS. 

MOVE  _P  T"  * T 0 :> . p T 0 ; 

r.>  ^ h I l r c *4 " v c p t o ^ * n u u. ) ; 


• / 


__  tiC_6NC.pTQ»Nf  xT_cr_E\C  ; 

Tend;’ 

-/*  we  ilst  uppate  the  q an*  vector  tc  reflect  the  pecro:-*  inc  that 

HAS  BCEN  CONE.  •/ 

/»  * c ELECl^T.  Siyi’LV  PfTP  TH£  Q AA  K VECTOR  SC  THAT  A0JAC6MT 

6LhMh\T3  IK  TUP  *PV!  0°PPP  '/PC  TOP  WHICH  HAVE  TH=  SAVP  m.0  3 ANK  S HAVE 
ECoAL  F w PA/’KS.  WE  t PSg  TmaCK  CF  SCPF  PARALLEL  ISM  MQW=vER.  */  

~ cl:w.crl=r*c  = D5w  «T ) V* 

PPcV.Rank  fCLffi.1-’  ank  { CU .^C3C6P  » ; 

Ncw_Ra\k  ) ■CUP.PAWK  5 

uc  Ja?  :c  C 1C  T l NO ; _ _ 21 

C UR  .OF  OP*1*  OP  OF  k ( J I ; 

»*;X  T_P  A . j K ~ P. a \ k ( CUR^PCE^)  ; 

IF  f,Ar.Mi'i^sOCSv_-,'iNK  THEN  OJP.ft  AKKa~ClJP_04NK*  l;  ~ 19 

**FW_F  Af\*  | CUR..0S.';FR  ) *CUP..0  ANK  ;• 

PwrV.RA.NK*NX  T^f.  *NK;  " 

E\n;  _ ~ . . 

R A‘iK  »Nr.».n  ANK  ; 


-/»  v*F  ,i , w ’*  i J i T 'toofu  Tug  CH  e\H  LISTS.  */ 
AUCCATL  c’»  f/.  j<  HOn0$l  5 
ALLwCATw  6'4  'iTiM  < *Lni'°S  ) ; 

j/»  "ivo  rut  "/ t i ,i*r  fjce  the  ltA'kcc  list.  */ 

OL.6  *»•"».» TH* ST A«*  T_9TI>  ; 

Lo'f.rvsi  : r «iccps  w‘-»lf<pc_eno_ptp-.*mjli  ) ; 

_ I CLIENT  / )*  'r. L CT*  ; 

t • _ L C C r*  — V *•  *■  ( p *•  f A ) «t  *1 C p .VAR  ; 

bf.jf  API  r-  r« ) *EVC.t  rc  ; 

Savc^ptp  *\‘P  x T— r*C-.F'?0  • 

F3cfc~u. .f-n.mi ; 

CL„6iC.pt<*Savp_o rp ; 

feMi;  

0/«  Si.vr  T He  P^FS»/.«ABLY  $FCF  f LISTS.  •/ 

Swt  TCHtS*'  t 1 3 : 

OC  J*  •auOS-l  TO  l **  -l  WH  !LC(  SWt  TCHFS)  J 
I rc»-cP*#of  «; 

Cu  I » i tc  J ; 

if..  L~ct  ? » >l^c  i !♦.!>  then  cc;  

T vp-^f-r  ( l . i ) ; 

T-Lr*4,P*0''„LCCP^*/A3  ( l ♦ l ) ; 
np  r ap,  ( i n ) sQctaw  ( I ) ; 

I.  r.C  ( l ) * TVP  ; 

rr'_Lnr  p^vap  U f #T_LCCP{ 

S*J  t c_He  S^'J  » 

Efin; 

FNO ; 

fcwc; 

Sw I Tones* • l • p ; 

DL  J*¥L;nP3-l  Til  1 PY  -l  taHf  J.F<  SW  I TCHFS  ) i 
SaI  TCH*S«lfl!*j 

OC  1*1  T r J; 

ir  en^tahii  ) >r*-!C  tari  t ) then  oc; 

rvpT?/  Profit  ! M > ; 

F N P T A f*  ( { +1  J *r \D  T AR  IDs 
c Mf TA*  ( I ) - T«p  ; 

JKIT/H.rjajjip; 

end; 

£NO; 

enu; 


•pki  ( ei>:>CNSTtM&cqc,S‘'»<?,77.n  t*i«Grctrtf  xropf  ♦ j» 

occlt's  r^ccs 

U/«  •uCftr*  TAXES  THE  STCKACF  ENTRIES  AX  Input  ANC  GENgR  A TfS  A l 2 

TAtiLfc.  THE  TArttc  CONTAINS  the  necessary  INFORMATION  FOR  GENERATING  l 2 

oeclarat ic\s  in  a Mien  level  language.  •/  I 2 

0 •INCLUHE  I\CL  IE  ICE  ILF  I ; l 2 

__  w.cluup  inci.  ic  icp*pcm ) : l _ 3 

s 1 *. c l c inci  Mirrieloi 5 ~ * i‘~  \ 

* I\Cl  U^c  INTI  IP  (CSFC  IR.lJ __  l .5 

41NCLU0E  INCL IKCANV)  ; * l 6 

♦Include  incl  ip  ( ct ape  i $ 17. 


MNCuinp  incl  menisci ; _ _ 1 

* I NCL«inc  INCL  IMn»FCG®PI  f 

J»UCL  '-AX.LFN.C^AMg  FIXEC.5 . 

*MA*_LcN_C\A Vfs J2 : 

grit  */ x_«_msmhcps  Fixer; l 

;yiX  s*  i* ; 1 

*CCL  *AX*_|\Te»I*$  FlXcCS. 

TMAXX.lNlgK  I*  $-*64; 

0 ’ CCL  l F lELn.CCL.F^CT^  EA.'fC  <<>*,  l 

/•  this  IS  Thf  PROTOTYPE  r c C l AP  A T I r\  CF  t ElglO  C*  INTERIM  •/ 

2 T Y 0 F CHAP  12  It  /«  ^Fn«  FCP_FJFlC  CR_ 'IN*  Fr,e  1‘jTFpTm  •/  

2 FTEirf_icV*i  F t XEO  llV”pEr*~ 

2 FI^L^.NAMF  C^AP (l c iGTh.KFY. NAME  I , l 

2 4 a x_; 6*? r f r fr.M  Frxec  cfcmi, 

2 F t ELO— T YPF  fwAU ( 1 ) , 1 

2 F ! c L ‘"'_L  **•_  T YPF  CUAR(1I,  l 

2 AX_i?N  rl*f*  (S,0)  .TCC  iv  At  t I 

2 *v  IN.L  r\  f I * go  |St0l”CFf  Ipa’i.  ' ; “ ’ " l 

0 oll  1 r H fj  c l_p«c  rr  pasfc  ipi,  1 

/•*  this  is  rug  pc  ptct yp  F cEcurATicN  of  a fil  = cq  a cFp^nr  •/  1 

? rvc'r  r hap  12  ) » /*  T1  • fC?  e !l  f TFCLAPATI.in  •/ 

2 FII.E. LEVEL  Flxgn  (31  CFC, 

2 c!lF_NA*fE  Chap  (L  ENG  Th^Xfi  Y^NARc  |j  _ l 

2~Mlc_cU)W  C hap  (l)#  *’  I 

? F I L C chaf (II;  1 

0 CCl  I °SCne''^CCl~PPCTC  *>a  SFC  (P),  l 

/•  Th|S  IS  Tmc  ppptotvof  OrCLCFATICN  CF  A AFCORr  C®  \ REPORT  l 
CnTPT  «/  1 

? TV»C  CriAkOI,  /*  *»f  • FCP  1 FCCF  r STRING  DECLARATION  •/ 

‘ ‘ 2 ^ ECC- o^lcvfl  c i x f n ”(3*ci  rgciyAt, 

2 - f.cnr  .g^namf  o/f  (va/_lfn_ca  A^r  >, 

2 -►C;J=r^LENGTH.TYPF  CH£P(Il,  l 

2 - FCncN_LF'  f.Tfc*  FIXED  ngC(5»C). 

2 C FF_*  rCNA  “F  CHAf<  ( M ^ X— L r AMf  ) ; 

0 UCL  l D^t.^PCT^  e.ASED  (P)#"  l 

/*  tm:s  c-nfral  ccc l t-p a r (Cf.  is  «;sEn  rr«  stpucti/rcs  •/  i 


2 TYPE  CHAF(2lt/»  * F p * FTP  F j l f.  NAPF  AT  TCP  LEVEL  ST»Ur.  T I jo  f- ; 

• pw»  RgCC'^C  CCL  AT  2\r  LcVEl  Hc  STPUCTUPE 


•GP'  F r p G° CUP  CCL  IN  ThF  STP«jCTU°F  ■/ 

^ LEVEL  FlxfO  n.OI  OCC. 

2 name  CMAf  (t  f *r  rn^KE  Y_NAyF I 9 l 

z '-AX.-FPFT|f  f.iN  FTxEr^CCC  l 3 I ; " 

-DCL  pint?  ( • ■ * x 1 n T c c I w S I rr  i \tep  , tp  Fixt-c  eiN; 

/•  A»p/.Y  CF  P.!I*  TC'<  TO  •INTERIM*  STCPAGg  ENTRIES  AND  X OF  THFR  */ 

OC I PNCHF  Chao  ( L r N G T g Y_N  A v g J J T a T I C ; 

/•  • PNuOg  • rc.,.;res  THF  p e z €N  T ”f  f (.  E •/  i 

o ..  GCL  RET^EVE  fiToy  (Chac  (i  ) r Ch  AP  ( * | V A ° , PC  I N T E ’ , (*)  PClNTEP..  1 

M*Fr  BINARY)  F X I F PNAL  ; l 

OCL  START  roiNTFfc  cXT; 

CCL  ChPTH.u  f»iTRY(CHAQ  ( • J )C  g TURNS  (CHAP  ( M A x.  L EN.CN  Av  r j v AR  | ; 

rCCL  max.xjiaw*- s rixCC;  l 

*v-x  x NAMrs*2N;  l 


_9 

10 

i l 


11 

11 
1 1 

1 1 

l 1 

12 
12 


12  _ 

12 

12 

13 

13 

13 


13 

l« 

I* 


l«  


16 
l 1 
l 7 


20 

21 


1 

3 


"v  t 'Tmtxm*. 


JJL PCt  J SP'IOCF.ABQ.  AY  A*f  $ ) , T ART.F  T_APR  AY  ( MAX.*.*  AMES  J • _. 

SC  Jsif  F.  T A°  GET...  ARRAY  tMAX~R_NAMFS  ) • F It  E~A  P u A Y ( MaX_  #„N  AM£  S J I 
PiM  r.jro; 

/*  Fite.AikfvAv  contains  the  POiNTgos  re  the  stopage_entf  ies  where  a 

F lL=  IS  0EC  !\EO  */ 

/*  tJi>?Cr.*.35 ay  ccr.T a r»:s  source  thy  files,  ta?cet_  appay  target 

LMf_FJ  LCS_  A'J^S^'T.CE.Tap^FT.Apc  ay  The  PCIMEPS  TQ.fH£ 

ST3K«Gc_5f»IP  IrS  whcrt  T u E ijPOAte  r T L F S A B S CEFJNEC  •/ 

0 oLL  I *S?tJkf  r_Ak  R AY  , * r AF.CC  T_AP*>  ay  , ASCUP.CE.rAPGE  T_AR?  A Y, 

yfii  Fixer  Sim 

/«  *SCURC£_ARS  AY  IS  TH  = NUMBER  OF  POINTERS  I N THE  SOURCE. 4PP  AY  •/ 


/•  /*  T inGtT_i3»  AY  IS  ThF  HIM*?*  OF  DClNTfSS  IN  r AC  G F T _ A»  « A Y ANC 

• S^Ui'Cc.TAPGFT.ARPAY  15  T*-F  MJVOC3  ~ F F(  I N T F P S IN  SOU3  C F_  T AP  G E T _ AO  o a Y 
“FIlt.AFKAY  IS  THE  Mlf*Pg5  HP  DClNTFPS  IN  FlLE_*.OMAY  •/ 

0 ” CCL  VJLL  «L»Il  Tin ; 

OCL  rllr_T!Tt.F  CHAP  ( i.evr  tk.kcy.n  £*S  » : 

JCL  FGkM.fP? r F f • T P Y ( P-*1'  I ’»•  T £ r T ► ! X = T ( 3 V,  F ! X E C C 3 ) I •" 

/*  PjSM.^fr  IS  A RECURSIVE  ?r<  T E CtK  F LSFC  FC«  T R A V E FSTI^  THE  Tpce 

In  p*cO*CEp  **/ 

• CCL  *AX_lfN_lNPLT  F I X £ C *. 

xfax.l***:. x?:pi; r * ice: 

nCL_srpiN*r,  cm  a=  ( x_t  1 \oijT  »_  va«  ; 

"cci  ST  anCAn  •■'..\>.*iE  CH IL  FNGTP.rfE  yJnamE  ) ; 

/*  S TP  I fiG  IS  YUC  THAT  IS  USUALLY  o7<$&c  >C  The  PRC*CBrURF 

HE  I « F vC  AS  TmE  Ff^sr  PAOamete  ■”*  . ST  1 A n A c C.nahE  CENCTFS  A STANCAPC  name 

us h l in  huiidi>c  r f e stc^agc.fmo  ifs  •/ 

s^CCL  FIlcTYPC  C»fM!«  <1  ENCTH.KFY.NA^E  ) IMTCiniP'l  STATIC; 

CCl  -.ept  r /.’•>  C^'AC  U FNGTH^Krv^'.avc  I (\ t ▼< • f if p r • ) static; 

/*  MLfTYPF  a***  °c'»TTy:>C  A:r"i/K  IV  3C1PJCVAIS  *' 

OOCI  C*  CHAf-  m static  I •:  I t « • I • ) , ancntt  Chaj.(2)  STATIC  trjtT(»Ci»lS 
/*  LCGlCAt  r«i- 0 1 Yrc  «;  ijs^C  ps  «ETt|FVAlS  •/ 
u JCL  TtM^„pfnDO_NAMr  CHAP  TL  ENCTH.kFY. NAME  » ; 

HCL  Tl*‘*,..=  ! I r_*i  A vr  C* 1 A 5 ILC'  rT  K£Y_NAf'F  ) ; 

rrt  :?_N  AMf  CMA«  < LfVC  CY^^  AMP  » ; 

/* 'TchpJp a“« y *ja *'r s”F'°  rtFTKifvrr  it^v^  “c  length  • iengyh_kfy_name*~  *7"  * 
0 CCL  S'VE.STTP  ACF.PTO  °c  i f t e *> : 

/*  S a v p S PC  ! Nrc'J  n S T r 3 A f s CNTcy  re  STHp  ACC  VECIU1*  CESCPJPTIGN  ♦/ 

0 uCL  F I L S S T PfiT^  YIC^Aw  ( »)  jpftijpM  ICHA3(2)  ); 

JCL  FILE.ST.TY0?  CHAkI2>; 

- STA*.fYA»*  •'E  *•  1 F ILr  • ; 

s T -Inc .s  >,7  AM  ;Apn.> .A'^F  ! r«  I'm 

Sr-Mvro.f'^ps'  S o e o f i J 
J JO  f N (}m  S T W I VC  I I s T AV'OAPC.N  AMF  ; 

CAI.l  -r  fJCv?  ( STS  |\r..  » ' . ST  AD  T .F  Tl  F APPAY.tfFTLE  ARRAY); 


375 


J 


J 


/•  GET  ALL  Thc  FILES  AfO  REPORTS  •/  l 36 

*Sw  VJPCF  .A°R  AY  ,#  TAhr.tr.  iP_c  A V •JiSfl'a  c E,T  AP  G E T . APR  A Y«c ; 1 36 

- U)  f » l’  T r *f  ue.a«*ay;~  ~ 

0/»  THEPOlNTEPS  TO  thF  STC^ACE  FN  T o f £ $ U*-ERf  The  SOLACE  FILES  ARE  2 38 

OIF  In €3  fir  = SE  T IN  MSOUt»CF.APO  A>M  l N OF  xEO  p y « a SCUH CE.  AP  R ay«  , 2 38 

THE  PC  J N T tr  5 TJ  the  STORAGE  ENTRIES  whTP  6 T H F TaqC-FT  FILES  ARE  CEFjnFO  2 38 

ARE  SET  IN  " T A R G f T . 1 F PAY”  l.\CFXcC  SY  ••  * T AP  G F T _ A4  P A Y"  A\0  THE  POINTERS  2 33 

TC  the  b TO  ~ fiG  ? F N TR  IPs  n F Th*  FILES.  WHICH  AP*~PtjTb  SJ'Jf-CF  ANO  _T  AHGET 2 38 

IN  MSCCp.C“E_TAROr  r_*r?  AY"‘ (NrexEr  o‘y~  H*SrLPCF_T  AMGFT..APH  AY"  */  ~ 2 38 

0 STPPAnF.orox^ iLF^ARt AY  II  ) ; 2 38 

F ILF.T  I TLF  *$  TC*  iGc^cu-JY  ,NA"F  I l I ; 2 39 

F ILC.ST.TYPPsF !LFSt(F I L E . T l T L E I ? 

/•FILEST  cfnjavs*  '5°'  IF  ThE  FILE  IS  SOURCE  GMY{ 

*JC, • IF  jHf  F I L r IS  TJPGE1  fur.;  1 S T«  IF  THE_f/lF_LS  ?QTH 

SCli®C£*VvC  T a R G F T • /””* 

0 IF  FIL£.ST_TYPF*«TG»  THEN 

on ; 4 47 

/*  IT  IS  A TAPG6T  Of.LY  F Ilf  •/  . . 4 48 

ATAWGH  r.A<»fi  AY*»TAPCFT_APPAYAi  : 4 48 

TAP^gT.APRAYC  ATApCFT,aFOAY)  »F  ILC.ARRAYI  I I ; 4 49 

enc":  “ " “ - '**  ^ "50' 

0 ELSE 

0 IF  F ILE.ST.TYPE* »SR  • THEN 

On;  5 52 

/•  IT  li  A SnV»C?  ONLY  FILE  */  5 53 

*snL,0Cr_Ap  9 ay  *«sru°r  f.apm  ay*  1 ; _ _ 5 53 

snimr.E.APc  ay  i «sclhcf_array  isF  ilf.appayi  n ; ~ 5 54 

F Mn ; “ 5 55 

0 FUST  4 56 

0 _ Ic  F IL c.5r_rY®c5 •$ r • T H c N 


I 


/•  IT  I j 


paavc  n ; 


oa ; 

A S^I-CE  AND  riorrT  FILE  •/ 

*S'JtJ®Cc.T  «»GCT_  SOH  AY*<sr.u9CF.TAHr,ET_A»P  AY^l ; 
SilUKf  E.T  av  CE  r_A«w  A y<  *Sou^CE^T  AS GcT  Japp  ay  } sf  1 lp.a 


/•  F.*iP 
AUO  «F 


E\o : 

ELSF  CALL  SYSEJR ( ‘CCCLTs • J | 

FILE. TITLE j | » NEITHC?  bCL*C=  NOP  T AP  GS  T FILE*); 

TNO; 

c-'.  hi  To  xsruf cf.a°p ay : 

Evt:-Y  srnaCF-r.NL y_fjlc,  generate  _jhf  CECLapa  t ICN*  of  the  file 
its  c Lr.r  ir  *7  ■ 

ST^acp_Pf&*srLf  fr.APPi'Yl  I); 

LOCATE  c'Lr.ia.PrrTC  F iLf  (OCLTABI  ; 

F !Lr.Cr  L.PFFTC.F  II.  E^NA^EsCHP  TP  LP(  STOP  ACE. ENTRY. NAMc(  LI  II  | 

• S' ; 

_f  IL E..nCL. PRpTr.F  I L E.F lCw * • r_'_; 

>*f  nV  i>«‘ r/i  r ooi  jarle*/ " 

CALL  FNTrP.FTLF.lNF*:; 

/•  Th*E  PP  iLCOHPS  FfFC  OE^PPATES  THF  PECOPO  STRING  OECLARATtCN  TAeLF 

if  the  argument  is  'i'  then  tr  input  , if  nct  , jltput  */ 

P IL  6. ST. TYPE-  #SP  • ; 

CALL_~c°rr  l l ); 

END; 
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53 
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59 

60 


62 
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64 
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cci i_gnr\R_  J*)_c.Ti_exXj 

2 ir'c  fixec  “IN, 

2 r.n.L(:np_vAC  Chap  ( r ach_namE_LEK  ) ; 

CCL  e-JuTAd  (")  FIXFo"°IN  ctl  F x r ; 

CCL  *LClP$  FIXFO  «1N  ext; 

0/»  I'-'PuiiTAM  L-;CAL  VAfc-MPl.FS  MSEC  PY  SUPPC'JT  I N ES . */ 

/*  *i.b.t'NO.LISr  I S THF  T p m o n p y ’f’fSITroY  re  Tf-E  SqIJNC  $ AND 

I T c.  »•  A T I 0 fc  V A ° | .*.  • t ~ S F c.7  rt-e'l.'*^PS  . [ T 15  * llN^CC  LIST.  THE  TOP  EL  T 
IS  ALWAYS  * FCCC  fuCEC  P Y ' « T A*  T_P  T ? ' . AT  ThE  ENC  Cp  THE  M A I N 
RCbll'if  Thl  LIST  WILL  ?E  f/\vci<fcC  l^r:  jrrayS  AAC  SC^TEC  p.Y 
LOCATION  l.\  THr  V F C T ® « */ 

CCL  L *A$ECI C?_FNC_PT» I , 

7 2 n-rj.  rc_  F_!  X c T_JU  \ , 

2 c\0-LnC  CI  xFf'~°l*'i 
2 LC'^.VA®  Ch Ac < F iC H_AAM€_L EN  ) , 

P NtrXT_DC_F^O  PTP; 

DCl  STAR  T.PTP  pto; 

/•  f./f-IE  „l7s  T IS  T Hr  LIST  CF  FCKEACH  NA*«FS  WHICH  STAPT  LCCPS  AT 

this  Pul nt...*/  _ . . _ . 

OC L l Uwcll  1ST’  hVscr  r\-.iMe"p  7P  ) f 

2 c7- C^NA^E  CHAP  IF  ACH_N  AMf  _tEN  ) ♦ 

2 NeXT .NAME  PTP; 

CCL  < ACH_P  TF  p r ■»  ; 

0/«  »:  THfw  V/-  I A#’  I FS.  «/ 

DC  L T.LGi’P  CHih  

CC.^  U.LiSt  . Sf»VE.PTP>  PTU; 

cci  (YcS^Ctr  (dict r o • Ncr.cFPincTtNcnFixFo  *in; 

oc l s m v E..L- p r - _ - 3 ( r f c ' i \ r i fixfc  mn; 

CcL  ( VCC^t*.  TP^S  •l-rCA',  PAPr.NCCF^,  «YES,  «Nrr,  VC VE  ¥ ) FIXED  SIN; 
CCL  LACT.CcW  FI<CT  3 I\: 

.CCL  l F N T ii  f »,  J,  T*'P)  F(XcO  e t St  : 

Cll  (Clip,  "rMS|  FIXFO  PIN; 

LiCL  S V.  | rent  S ° I T ( l ) ; 

CCL  -'JLL  *•  u 1 1 M n ; 

ccl  Ncrc^rvoc  cm^ku 

CCL  «E  C.PT-  PTP, 

L •';ve_3FC_F|.  p > A ^ciC  (^n.VF_P  TF  ) , 

2 F l L r— *'  A '*  f fW4P(  L^N.r  ICr.ENTe  Y ) , 

2 FEC.':a**E  C u A p | iFN.rfCT^ENTPY), 

2 ..cxr.PA m pt*; 

CCL  r ;p_P  Tf-  Q r<’  ; 

CCL  'M'.vrn.ronrs  F'xro  PIN; 

. OC  L ( TiOVE.j,'  '/  T.L,,C  , J-CVC.*  ^QEjClCrX!^!  , _voVFC.C»-OFP  ( CICT  INCI  ) 

r f X * */>  HI-  ; 

Cll  ?.!■•;<  (*)  rrx  = H op-  rxi  ctl; 

CCL  ,rVi.Ktlt<rpr(  ,rj  «lxrT  pin; 

CCL  A».k  # oocv.P  AA  * ,NXT^RA\K  I Fftt^  pin; 


no  i*i  to  *t aocft.aoc ay; 

✓ • TH«f  SAlc  Thing  I S OPNF.  fOQ  TAer.ff  CM*  FILES  •/ 

5 r^c  •fe_PT p-ta^ff t^app ay ( l i ; 

Lnc a r f r !i  e.oc i_pprir  r i l H ff  L tab  ) * 

fJLf  .DCl_P»njr,FJ_l  E^NA^fsr  HPTPLP  I S TOP  ACF.ENTP y .namF  ( l ) ) I I 


FILc.nCL_POCTC.f  fLf_FtCW*»r» 
/•FILL  UP  FILE  CCL  TABLE*/ 

call  fntfp.**  ite.fNFr; 

c !L?.$T_1  YPp»«  Tr,»  ; 

CALL.  FifCC?li 


/•GENERATE  PFClAPATIfiN  PC4?  INPUT. OUTPUT  FILFS*/ 

OP  I * l To  'ii'>i:pCF.rARtr,ET_AP«  ay  ; 

ST?=  AGE.PTPaSCG^CF.T AWCF  T.AWP  AY ( U 5 
LOCATE  F IL6.rCL.P°CTn  F I l E I nC  L T A f* ) ; 

_PJ  L E_OC  L_?°pT_n_.  M L.f  .N  av  e sf>p  r R L ? C S TO®  AGE.EN  T<?  y .NAM6  ( l ))  | I 


F ILF.CCL.PPCTf.F  ILE.FLCVM'U*  ; 

/ • f ill  up  f Ilf  ocl  table*/ 

CALL  FNTFp.F ILF.INFC; 

F ILf_$T_TYf'Es'ST»  ; 

£ «._F G3.  _A>_uP? A T - fT t E _TV*G_f  F ££PJ} S _ A «£_.€££ £ P A T E.O . * / 

CALL  ngci’ll! 

CALL  Face (21  ; 

FN? ; 

- On  1*1  Tn  * SOURCE. aoo ay; 

✓ • GEN  £r  A T I \'G  The  TABLES  F;q”thF  STRUCTURE  WHICH  FAS  ThE  file 

_AL_L  -:v  = L_C'iF  _*/ . . _ 

STTp  ^GC.°TP*^nijPCE.ApPjfY(  I I : 

|1  ST,,OAr£_FNT*v.NAHE(  ^ ) ; 

/•  T h t PaOCc^J-41  To7vERScS  TFE  T CEF  GENEWATEG  BY  ThE 

FILE  STrLCTU*e  IN  p ■<  ECO  OEP  •/ 

CALL  FCoy.TPEc  (Or»pcF.  appay  ( I ) , t , 0)  ; 

CMC,; 

0 .jo  I ** l ~T n srTfcCFTTAoc  ay: 

ST?^AGE_PTO*T/»PCE^.AcF-1Y(  I): 

/•  'P*:C?c*  13  A CLOPil.  PA"('Mr  T F c rc*o  THK  PPCfFrUPF 

/•  IT  la  XsCFSSA^Y  rc*  Tfp  ‘PSTFEVE'  PPCCECL'PE  »/ 


• fqpm_ r*F? • • / 


P^  **0E*  • SP  • | I STroACF_PN  TPY  .AANFC  l ) 

rMt  FfiPl»_T»»EF  ,C)  : 


JC  r*l  Tr  YSrLPCE.TAO CE T.AC OAY  ; 

STi  • AGc_p  TO  = Sni.t  C F~  T a * GT  T_  acc  »y  ( f)  ; 

PNCV  * • *p  • If  ">>r‘cArr'jN  T s Y . A A v F ( l ) ; ' 

*»  e-*M  $t  C(lES»  FOP*  T*“c  Ttcc  $T/OT!Nf  / T 
THf  'CLO.*  WILL  fall  at  LcVFL  l */ 

C/LL  FCO-.TSEECCUOCE.TAACET^APO  ay(I  I ,2,0 


/•  FINJ  rvTffPlM  NAMES  •/ 
“ST  A A^O.“a“F**i  I U.fo  • : 
CALL  f\E  TOC  v- ( STAUCAOC.UA'- 
LC  r = l TO  *P!».Tr-; 

ST'*'1  ACc_PTw*P  IKTP  t 
0 P * i) A TA*P  T ; 


ST/P.  T,Pl\TR,J/P[NTP) 


l ’gatf  f rci_?^rrL-oocrr'  crLFircLiAei 

” p I Fl.O_NAKr*sTrP  ArF_F\  TOY. NAK  Fill; 

F KLfCnrt  ,porrrt.  TYPE*  ' IN  ' J 
e t cLrlLevFL-2 ; 

r f r ific.c ici r. typcso  thfn 

F I SLP.OCl  .PP  f TO . F I CL  r.  TYPE*  *C'  ; 

t L r-  c 

■fF  F IrLr.F  IrlC.TYPE*  l THEN 
c l F|.  n.ff  L.p®  GTC  • F IFlC_TYOF*M 
EL3t  IF  FI  Ein.c  IFL^.TYPC* .1  THEN  eI  FI  O^UCL.PPC1*:  .F  Ic 
cLSt  F I CLO.DfL.PPC  rr . F f CLT.TYPF  * • F » ; 

IF  F I tLH.r  |FL'*.I  cN.TYPf*0  ThFN 
F IFLC.XL.opG  TP  ,F  | El  C.LCN.TYPF  * • 
b L c f 

FfCLn.rc L.Pcrrr  .Frri c.lfn.type** 

MftT.LFw*'-  I EL"  .F  I cm^Lc?  .‘'AX; 
vl\.LT  N*riFLO.F  IFLG.LrN^K  IN*. 

f IclO.ocl.^op Tr.»» a y^Pt pf  T I r icn*o  ; 


U F ( CCLT  AB ) 


FMCC  : PF°C ( IP  T YP  t ) ; 

/«•  THIS  Ruorpic  FpRvS  'MF  OFCCPC  STRlNr  CECLARATICN  TABLE*/ 

rrt  mtvpf  f i x fo  ofc  < 1 1 : 

/•  i*  input  ,2*n/rpur*/ 

CCL  ^FVlrFI2ICHAom!MT|  •CAPC  S'  . • PR  I NT  5 R •_}  J 

” T CMP^r  I tC.N  /»re_cN  f »y  #n  a vc  ( j 

TE  *u. R fcr  CP  P.N  A f'C*STCF  ACE. EN  TRY. NAyEI2): 

Lf'CATF  - FCP90_PCL_P|,l.  TT  F I L F I CC  I.  T 48  1 ; 

R ECH* P.TCL. PR CT  'J  .0FCPRn_NAVF*OP  TRLP  ( TF vp.RFCORO.N AM E ) I I 
•.S’;’ 

IF  F_!  I_  £_  S TYPE  » * S T • THEN 

* /aS  1 1 E^PCTm"  sT'^RCc"  ANC  TARGET*/ 

/•MOniFY  RECORD  STRING  N AM  £ WITH  PREFIX  'OLC.*  CR  'NEW.* */ 

m; 

r f iptyp^si  then 

0cC0Rr.PCL.PRCTl3.RcCCRC.NAyF*  ’ CLO.  • I I 

* tCPCQ_OCL_PKCT‘i.P  ECCRC.namE  ; 

ELSE  " 

3 crnoo.PC L_ PRCTp . R F CC R f _N Ay E * • NF w. • I | _ _ ... 

R ECOROlrCL.PPCTC.c  FCCRC_NA*E  ; 

PNO;  ~ 

RFCCFf>.r!C  L.PRC  rc.TYPE-'oC*; 

R FC^.3 n^C  l”?o  FTP . ? CCP«  C_LFV£L*Q  ; 

I F $ TPC AOF.NAVF* • "•*  THEN" 

/••if  stcragc  \a*f  spec  iFiec; 

SC  r OE r ALL  T PEC-IkO  LENGTHS*/ 

_ OC; 


- t 


»cCPPO.CCL.PRCTC  .PEC CRC. LENGTH. TYPE*' F*  ; 

IF  TcTYPFM  THPN 

° fccr  c rcL.p  = cTc.Pcccpr.iENr-TH*^o; 

ELSE 

__  R FCCCC.CC  L.PR  C TC  .PFCCRr.L  r_\ GTh*  l 20:  

CALL  P^APN  ( ' I Vc’y PL E T ENC-  S S ) : S TC w AC E WFC|!JH  F n ® F I L E • I I ““ 
TFV7.F  ILf  .'lAME!  I • *•*  T < s T V C ; * | | C? V I C £ ( IC.TYPF)  | | • ASSUMED*/; 
ENP; 


13* 


133 


135 

136 

136 


_/*  SFT  f:r»  (Tata  Tdm.f  PCINTFP)  TO  THE  STORAGE  __  _ 

net  I uy  ncsrcjpricr  storage  e n t e y That  was  Saved  *7 
C'f>*S\VE-ST''?'  AGF-nTf>->CATA<i.PT  ; 
jr  A^Y.srvr.  rypc  = »rapL'*  M\Y.S7Mf  .ryp£s*pf,-CH*  then  5 

oo ; 6 

‘TFC'jP^.PCt  „PwCTC.PFCC?»0.1F^GTh.TYP6»'F«  ; f. 

°rcr-n^nci  p’ctt •P‘‘cc*n  ifmgt>«bu5  t 

Err;  ’ * * 6 

IF  AN  V—  S Fm  T • T Y Pr  * * r f SK  * I Af r.STMT. TVPP*» TAPE » | 

ANY. S TNT . TYPf» • TgRN • THEN 

oc ; 6 

IF  CISK.PECFN<2  *HEN 

cr ; _ e 

RFf.r^n_CCL.PRr  TC  .~SCCRO_t  ENG  Th.Typf  « ' F • ; Q 

KFcr*nIrr.iIpRCTC.pcccRoIiENGTH=c[SK.LP.eci;  e 

c\0;  8 

....  ELSE  . 

on ; 8 

C err °0_rCl_peCTC .PFCCPT-LFnCTh_TYPF  s'  V • ; 8 

Recr-rlrcLlpwc tc.pecocIl  cngthscisk .lfecl : 8 

ENO;  8 

FNO;  6 

IF  ANY^STvT, TYPC* 'PFNT ' THEN  5 

OP ; 6 

accnrn_rct  _P»C  TC  , PECC^O.l  ENP  TF_  TYPE-*  • F • ;. A 

PECPPO*rCl.IPRCT0.RECC*<0lLcNGrHaL20;  ’ ~ 6 

6N0;  6 

END ; <, 

3 IF  PECnP0-0CL_P9PTn.FEC'DRC_LENGTH.rYPE*'F  • THEN 

cn: 

/*P.IN'P.  PEC  PRO.  AAV?  OVE'L>HCH  RECC«C  STPJNG  WILL  06  CVERIAIC*/ 

IF  F ILT.S T.TYPF * • S I • Then 
00; 

IF  IPTYPF-l  THEN  « f CC« O.CC l _ P P r T C . C 5 F.P E CNA M E * • CL  0 . ' I I 
CF'PIRLM  T f 'P_F  ILC.NA-F  ) | | • . • | I 

7E«P_pECC°C_NAMF ; 

RECfTpr^CL.  PRO  TC.rEF.fr  ECNANE3  'NEW. ' I I 

C HP  Ml;J(  TL.SP.FILF.rjAMF)  If  * . • | I 

TE:iP..PFCC»O.NAvc  ; 

CNP ; 

FLSt  PfCnRC.CGL.PPPTa .PEF.PFCNAMFs 

ChptrlaiTc^p.filc^nahf)  U MTFMP^FcCVC^AyF.; 

CMO ; 

else  «ecofo_ net. ptct^ .qef.oecnanes • •; 
fn  n fdft.  : 


■w  v , : 


lFCKM_TPCfr:  PRPC (nFF_S_E  ,T_LEV£L .HaX.REP)  »ECU»S[VF; 

O/*  THIS  PROCEDURE  GENERATES  TABLE  FNTRIFS  REPRESENTING  THE  HIERARCHICAL 

F tCOwQ_S  IF  LC  T up  6 

o ret  Savf.ptq  pcintfp, 

. /*  'SAVF_PTR  • IS  L'SEO  TCR  SAVING  THE  STOR AGE_P  TR  IN 

H£  PWCCEOUWE  FCRH.TREE  */ 

OEF.S.C  PCINT.EJ5. 


2 185 

2 185 

2 185 

2 185 


/•  nFF_S_F  IS  THE  POINTER  WHERE  NCOE  WHICH  IS  THE  ROOT  OF  TH 
E SUB  Tc  E F TP  PE  TPAVEPSEC  IS  Ct'FlNFD  */ 

T_L  r VF  L F I XCD  CECl 3 ) ; 

/*  T.LEVFL  IS  THE  LFVhl  CF  THE  NCCE  IN  THE  TREE  */ 

CCL  max_p™  FIXED  decimal  ( 3 > ; 

/•VAX.KcP  IS  maxTh'JH  NUHB'EO  CF  RF°ET  IT  ICNS  O’F  C-RCUP  CR  F l ELO  •/ 

CCL  TE^P_MAX_REP  fixed  0ECI3);  

CCL  II  F I X F o bin: 

OCL  (JJ,  ■'4**111  f’i  XFP  Hrw  STATIC; 

CCL  NODE  CHAP ( LcNCTi  _KFY_NAMc ) ; 

/*  NCC L IS  THE  NAMC  Th*  NODE”*/ 

r-CL  * ST  ArV  ( yAX^A.M.EMpEPS)  PC  I N T EP  ; 

/•  ‘STACK • STOICS  THE  STHPACE  POINTERS  CF  THE  CESCENCENTS  */ 

ocl  «stack  fixed  binary: 

STOR  AGE.P  TR-sOEF^S.E: __  

CP«OA  r A_PT ; 

fp  AVV_STvT. TYPFs* FLO  1 THEN 
CO  $ 

/•  IF  THE  STRUCTURE  IS  A F I FL  C THEN  FILL  IN  THE  INFO  ON  ITS  OCL  •/ 
LOCATE  E ICLO.OCL.PRCTC  F ft f ( OCL T Ae > J 

FIFLC-NAvE*STOPAGF_E\TPY.NAvE(  l ) ; _ _ 

F l ELO_CC  L_P°C  Tf) , TYPE  « ' FC  • ; 

f : f l°.lf  vf  l = t.lf  vfi  ; 

I h > IELCTf  lELC_TYPt*0  THEN'' 

PIELO^DCI  P°CTC  .F l ELC.TYPE^C*  : _ _ 

C L 3 c 

IF  F lElO.F  IELC.TYPE* l THEN  __ 

F lELD^CCL.PPCTC.F I EL C_ TYPE* *9 • ,* 

EL  S F IF  F_:  - I_  D ._c  I - !.  o _ T Y cIEn_nCL_P0rTC.FIFLC_TYO6«*N*; 

cLSL  FlfcLC.CCL.PPCTrTp'lFLC-TYP'EVic*'; 

IF  F IELD,FIhLC_LES_rYP6sO  THEN 
FIfcLC_OCL_PPCTC.F l EL C.L EN.TY PE  * » F • ; 

FUSE 

F IELC_CCL_P°CTC.Fl c L C.l EN_ T Y PE  * ' V • : 

MAX^LPNsPtELC.F  I FM.IEN.VAX; 

BIN.lE  •i*FfF'LC«F|FlC.LFN-.MINV 
F I ~LD_nCL  ppprr.^ax.PEPFTIT  ICN*«ax^rep; 

E*iO; 

ClSF  __  _ 

o on; 

_/*  IP  The  S TR  IJC  Tl  P r l S_  NO  T A PIFLO  THEN  TP  A VFR  S6  J=LR  THER  IN  __ 

PMECK'JLR  " *7  LOCATE  CCL  .PROTC  F l L E ( OCL  T A8  ) ; 

OC  l_ P«0 TO.  LEVEL *T_ LEVEL  ; 

9CL.P°GTr  .NAMFaSTOBAGc^FMRY  .NAV6  ( U 5 
0Cl_PRf)TO.HAX_PFpFr  IT  I CN * * A X.R E P J 

Tf  ANY.! T^T  . TYPFs » F l LE  • | ANY.STMT  .TYPE- ' 0 6PT ' TH  CN 

oc; ’ 

CALL  R E T P E VE  ( S T OR  A CE  .FN  T R Y .N  A *^r  I 2 J II  ' C *1  I PNOQF  , • 
R ECO* .START .STACK  ,XS TACK)  ; 

IF  * S r ACx  *C  THEN 

CALL  R ETPrV6 (STOP AGC. ENTRY.NAmc(7)  | | .t.  | | pNn0 
E » 1 K P TN • , STAR  T, STACK , 0 STACK  ) ; 

nc  l_pr^  tgj*_typ  f » ; 

CALL  FCR'h*  TR  E El  S T A~C  K C l > i T.LCVEL  ♦T.  C*l  ; 

RETURN;  _ 

FNC;  ” 

IF  •VJY_$TMT.TYPE**»fcCO'  I ANY.ST.MT  .TYPE*  ' RPTN*  THEN 
ocl. proto. rYPE**RP • : 

e IS  F 

nr L.PwoTn^  fvPFa »cp*  : 

SAVF.°TR«STn>AG?_PTR; 

DO  I I *2  TO  FYS-2 ; 

/f,  rrv  £ ACH  CESCSnCANT*/  _ 


2 185 

2 185 

2 185 


2 186 

2 186 
2 187 

2 187 

2 188 

2 189  1 

3  190 

4 19 1 

4 19  2 
4 193 

4 194 

4 195 


5 198 


5 ZQO 
5 201 

5 202 

4 _203 

4 204 

4 205 

3 206 

4 206  2 

4 207 

4 20  7 

4 208 

4 209 

5 210 

.6 211  _ 

b 212  3 


7 ? 1 4 

6 216 

li 


6 ? I 8 

5 219 

5 220 

5 221 

5 221 

4 222 
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/•-fbfcRe  ah*  «KEYS-3  SURTUFFS  •/  5 224 

NCnE«STC«AGE_f.NTCY.' AMFf  III:  5 224 

/*M\n  put  hmi»  *any  times  the  kfmber  rfpe at s*/ 

ME m Is  I 1-1  ; /*  The  *c"P EP*  IS  l L*SS  THAN  II  •/ 

ip  rfc.gr* «»sijp i vem< ) «o  then  temp_**a k~i?p*c; 

ELSE  IF“'PFCrpP#  fSUi'-C  **EK«)al  T HFn’t  E mP.m  ax_R  ER* 

RFCGOP . F I o S T SUP ( MEM  * I ; ~ _ _ 

ELSE 

on; 

/•THFRE  ao  p 2 SUBSCRIPTS:  IF  THE  UPPER  IS  1 

IFCfOsUl  THEN  F I CL  D IS  REALLY  jijST  OPTIONAL? 

THEREFORE  PRFTENC  II  OOFS  NFT  K FP  6 AT •/ 

IF  PECGflP.SECruC^SUPlREH- l»l  THEN  tEmP_max  REP*0; 

flse. 

_ TEMpImax.REPxPFCCOP.SECCnC^SLBIMFm#) ; 

eno: 

CALL  RCTPfVF  (NOCf  f | « CM  I PNTTE  , * * . S T AP  T . S T ACK  . 

•STACK); 

/•  FIND  WHERE  THE  NCOS  IS  06FIMFC  •/  6 23C 

Jj-l; 

STOP ACE_P TP *S T AC k 1 l)  ; 

no  WHILE  ( STOP  AGE.ENTHy  .KAMF  ( U-.NOOE  c 

JJ<«FST4CK)  ; 

jj* jj*  i ; 

STUPAr.E^PTR*STACK(  JJ  ) ; 

FNO ; 

_ IF  JJ>«STACK  THEN  CALL  SYSERR 

(•nrcLT:  mf * off  kct  fcukom: 

CALL  _FCR?'—  T F Cp ( 5 T J C* ( JJ  t .T_l£VFLM  , T Emp_*A  X_»6  p ) ; 

STOP  AGE. PTP*SAVE.PTC(  ; S 233 

OP^OATA^Pf; 

FNO;  5 234 

ENO;  4 235 

ENO  cOPM_T°EE;  2 23* 

iENTFP.F  I LE_ I NFO  : 00 HC  ; 

0/*  THIS  PW'\C  EntlRE  cNTFPS  THE  REGAINING  INFORMATION  INTO  THE  FILE 

ceclaraticn  table  •/ 

oocl  RHcOiMAx.rf.MAi-csi  pointer,  *p*f-r.  fixfo  etm 

/*  V M F 0 IS  APPAY  QF  °OlNTEf,S  LSFC  f’ELCw  IN  RETRIEVING  MEDIUM 
LESCKIPMCN  STORAGE  ENTRIES;  *pmEC  IS  THE  NUMBER  OF  SUCH 

cf.  TRIPS  R E TP  f F VFn.._  */ 

riLH.OCL^PPOTC #TYPcs*  FL ' ; 

FlLF.OCL.PROTr.PiL6.ievFL*05 
/‘OEfFPMlAE  file  ORGANIZATION*/ 

STnpAGF_MAME*STCfiAGE«FNT»Y.NAH€l31 5 

IF  STGP AGt_NAMF*»  • THEN 

COj 

r ile.ccl^ppctc .f ile.crg * ' s ? ; 

OC  TURN; 

ENO; 

6LSF 

/•RETOEVF  MEDIUM  DESCRIPTION  FNT»Y.  FOR  INFO  ON 
LK_c_£RCAN  { 23  f tCN  


CALL  RETPEVGISTOPACe.*' AM^I  | A N n N'  C T | |FILETy«»6I  I 

ANONC T | | &EPTTYPF»* • ,STA*  T,PtfEO«0P*ED>  S 
. if  «PM£r*o  then 

CALL  SYSFPP 

(JDACLPNO.  M £ C 1 um__£ ESC  . f cp  * I ISTCp. age. name)  ; 

SAVC_S  TOO  4G=_PTD  = pvrf)  ( V ) ; 

pp«SA VE.STnoACE.PTR ~>CATA_PT ; 

IF  ANY.STmT. TYPE« 'DISK ' THEN  F I L E_OC L. PR CTO  . F I LE_ORG* 

0 I S<  .organization; 


FLSE  F ILF.OCL. PROTO. F 1 LF. CPC* #S» 
ENO; 

OENC  FNTcP.F  ILP.IN^OI 
- cNC  COCLT; 


' 


r 


4 
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•PROCESS! • N$T ,N*G6N€Nn%?ACRC«Ts  I 

_Gti\fNUj^  r-'fif'C  ( Pinw.PTB  ) ; 

/•THIS  ;»RCCFm>c  GENERATES  THE  »ENO*  STATEMENT  GIVEN  »Y  THE  FL0WTA8 

ENTRY  POINTED  TO  NY  F LCVi_PTR__*/ 

ICC  L PAX.ltN.NAME  c|X£0; 

xmax_len_namf* io;  

UC  L FLC^PTR  on  INTER;"" 

OCL  l FlQ WT  AB_PRD  TO  PASECfPI, 

2'NUoii  FIXED  BIN, 

2 TYPE  CHAR  (4^s J, 

P*F  LGW..P  Trt ; 

IF  fcU)E«*0  THEN  __  

/•  'EM)*  IF  FOR ‘ FNO  OF  GENEPATFq' HCCCLE;  Tf-EPEECRE  IT  GC£S  AT  ENC~0 F 

* PL  l PPQC*  FILE  •/ 

" CALL** 

wppl  l ( • C.iC;  • » ' pl  l PPCC  • I ; _ 

ELSE  /•  END  IS  eQR  A HATCHING  'DC*; 

7>fcR£Hy*ef  IT  GPtS  IN  0L16X_FJL£*/ 


CALL 

W*Pl  l(  • END;  »7'  ° 1. 1 c ;<  • ) f 
ENC  GENEND; 


• PR'JCE3S(^NST,N*  DFNOC  TC  . »ACPC«  I ; 

GCNGuICs”"PkoC  ( F LU’il'PT  P I ; 

/•THIS  PROCFO'.IRE  GENERATES  A DCTC  ST  A f f M F N r L Art  CL  INCICATEO  IN  "GOTO" 
FLC*Crtu«T  ENTRY,  WHICH  IS  PCINTeo  TC  PY  ' FlCW.P  TR ' •/ 

<LCL  m^x^len.l^pel  fixcc; 

•^Ax_LcH„L*\pELsIA; 

OCl  CHpr  PLP  <rNTP  Y(QAM*H  P £ TURN S ( ChA k ( 3 2 ) VA  W ) ; 

“DCL  ”l  F L C w T AH  — ao  r TP  GASECIP), 

2 NC'JFA  F I XED  BIN,  . 

2 TY*>r:  CHAP  (4)  , 

2 L Atj  r L G map  ( V AX_l  E\'— l A 8 El  I • 

OCL  FLOW.PTP  OP  INTEC; 

P*F  l CW_P_T fl j 

CALL  WPPL  l ('GO  To  ' I ICHPTOLB (LAPct  I I I # * *PLlcV*  I ; 

END;  


•PROCESS!  •NST.N*GcNLABf.MACRCil5  . _ . 

GFNLAH ; Pki'C  (FLOW^OTF.  I ; 

/•THIS  PvGC  F'JIJRS  GENERATES  Th£  l A 6F  L INCICaTEH  fit  The  FLDWTAfl  ENTRY 
PCINTLO  Tu”hy  ' FLQ'*r  OTP  ' •/ 

«cci  max.len.la^el  . rixECi ... 

A X _ l £ * J_  l /.  b C l s 14; 

UCL  i FLC’aT  AB.POCTO  BASSC  (PJ.  t 

2 Nope*  Fixcn  bin, 

2 „TYPF  C.HAO  (4  I , 

2 "lAoEl  C H A o ( y A X _ L E N _ L A P E L ) ; 

OCL  FLUh_PIc'  PP  INTER  J . ...  

CCL  ChP  TRL  3 ENTpY(  ChAR  l •))  R ETIJRNS  ( CHAR  ( 32  ) VAR  ) ; 

p»flow.ptr;  . . _x 

CALL  Wft?H  (CHPT  Rial  LABEL  ) I 1 ' s J*  » 'PLIEX*  I J 

ENO; 
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*>RCCCSSI  »NST  f*ACDC,k*GF\H  T , (2,  > 2 , l ) • ) i 

GENFlT:PRCC; 

/•THIS  P«OCPHUR£  CALLS  ROUTINES  TC  CENFfiATf  THE  FLOWCHART  TabLE*/ 

/*  k£  USe  THE  OROFK  VpCTCR  AND  DICTYPF  TC  CALL  THE  APPROPRIATE 
PCUTINfc  WHICH  WILL  GENERATE  THE  CO *R E SPCNC  I N G FLOWCHART  R6CORC.  •/ 

J I NUUO E InCL JG  1C 0 1 c T ) ; : • 

OCL  ZttTkTUn  T r Nnl  FIXED  PIN  EXT  C T L # 

/•VtCIUR  OP  CROC*  OF  NODES*/  _ 

J FIXED  BIN,  Cirr*  FIXED  3IN.  TYPE  CHART  A 1 2 

OOCL  l FLOWT  Ad.DUMwv  8ASED(FLOKTAe,PIR)  , 

2 NC06*  F IXFO  R IN  » 

2 NCOE,yY°g  CHAP  ( 4 I .. 

2 NuOE_NAm£  CHAR (LEN.OlcfTFNTRY) ; 

CCL  RCONCAS  c I X EC  PIN  EXT;  __  _ 

/•COUNTER  FOP  • OF  ASSERTIONS  THAT  ARE  CCNC I T lON'AL*/ 

O/*  Wc  SIMPLY  EXAMINE  EACH  ENTRY_IN  THE  VECTOR  A NC  CALL  ACCORDING  TO 
US  Ty»6.  •/  ~ 

__<CONC  AS^Cj 

/•INITIALLY,  no  NODE! ASSERT  ION  USES  A CfNO I T I ON A LLY^C OH PL ET  ED 
FUNCTION*/  


-LCCP:  DC  J*l  TO  CICTINO;  1 

0 C ICT  A*0Q0£o  (J)  i 

TYPE*OlCTYpc (CICTX I ; 

-/»  CHECK _Q0_  I A PL  E__f  C P POSSIBLE  GEN6RAT!  CN  CF  A PQ»/ 

"'“call  CHECKD^uV;  2 

0 /*CHECK  CCND^TAPLE  FCR  POSSieiF  CNEPATICN  OF  C006  FOR  CCNniTIONAL 
COMPLETION  OF  ASSERTION*/ 

CALL  CHECONCICICTR! ; 3 

-/•  CHECK  THC  •LABEL"  TABLE  FCR  PCSSieL?  GENERATION  OF  A LABEL  •/ 

Q CALL  CHFCI  AEIOICTA)  ; 4 

-/•(.ALL ' APPfcCPR  l ATE  "SUPPCUTJNP  TO  GENERATE  A FLOWCHART  ENTRY  FCR  THIS 
TYPE  •/  _ _ _ 

- IF  T YPE  * • AS  T C * THEM  CALL'  I DA  $ SM  C I CT  * f;  “ 5 


ELSE  __  

CASES:  00; 

IF  TYPE*  *R  FCO  * THEN  CALL  ID  ICCC  I C I C T » ) ; 

ELSE  DO; 

IF  TYPE*»FLO  * THEN  CALL  ICFLDAS  Id  ICTA)  ; 

else  do; 

IF  TYPF*UNTR*  THEN  CALL  I CF l C A S ( C I C T * > ; 

EL  SF  00; 

I F TYPE*  *RP  TTI  * THEN  CALL  ICICCC(CICTI)  ; 

ELSE  DO; 

IF  TYPE* ' M00L * THEN  CALL  I CMCCttM (CICTf) ; 

ELSE  nn; 

/•  GENERATE  CtlMMY  cLOWCHAP.  T ENTRY  FCR  ALL  CTHER  CASES  */  

LOCATE  FLOW TAP_CU*MY  F I L E ( F LOW  TAB | ; 

ncc  f **C  I Ct.# ; 

NcOt'.T  YP£*  TYPF  ; 

NCCE_NAMF*CICT(OtCT»)  5 

ENC  cases; 

0/*C»*fcCK  FCR  GENERATION  QF  ENO_CF  ICCP*/  _ _ 

CALL  CHLCENC  ( J I • “ ‘ “ * ~ ~ 6 

END  LCC?; 7 Q 

0/*uE^EKATE  CODE  FOD  cNO  CF  PROGRAM*/  f 

CALL  ICR  SET; ; _ 9 

CALL  IOCCTO; 

call  i dp  in; _ 


call  ioenc: 

OCLCjSF  F ILEIFL OwTAp')  ; 


/•  THE  FLOWCHART  TARlp 
CLOSE  IT  AS  Ct/TPUT 
_ FUK  INPUT.  »/ 
-ENG  G EN  rift  * 


(FiLE  ‘FLCWTAP*)  IS  COMPLETED; 

, SO  THAT  SUBSEQUENT  routines  CAN  OPEN  IT 


*4* . 


4 
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J F»!ST_pqpC  CH3S C LFNCTh.KEt.NAMg ) 9 

3 A*  ! TY  ° If*  F I X 6 C ( 151  * 

3 cATA.TVPf;  _ CHAP  ( 1 ) f 

/•  C « CHARACTER 

Pj»  H I NARY 

V ■■'PIXEO'CECI^AL  •/ 

3 r IFLO.LEN.TYPE CHAP(i), 

/*  F * PIXFO 

V • VARIAPLE  •/ 

i MN.lfKCTH  dfN  FIXECU5)* 

3 *ax_i«ngth PT'_L!A5r  1 lli* 

3 LFN.^CT  CHAM  (IFSCT^.F*EV.KAI»C  IS 


\ 


$ 
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— JUL  LNPTRL&  ENTpv (CHAP( * ) ) P E TUP N S I CH AR ( L EN_C I C T.ENTr Y | VARY  INC ) • 

ocl  sysepr  fntkycchar (*ti ; 

CCL  WRPL1  FN'Twy  ( CHAP  ( •)  V AP  Y I NG  » CHAP(»))S  

OCL  PICTURE  r%T»Y|HlN  PlXPrMlSn  RETURNS  !CHAP  ( 10  IVAPYIMGI”; 
_CCL_SUoSCR  IPT.STP  INC  JFNTQ  Y_PE  TURNS  (CP  A*  ( ICCI  VARY  INC  ) » 

ccl  !NT>Vc'e>riw'rpvi*=ii'N  rTjrpnifsTi  kfiurnscchapc  ji'fj 

CCL  pack  EnTRvirin  FtxEn<L5)l; 

CCL  UNPACK  6NT0YIRIN  FlXFD<l5#ll5 
CCL  PLlSTw  CHA^f3?0)  VARYING! 


/•  THli  is  the  VARIABLE  IN  WHICH  wE  FORM  THE  CCDE  FOR  THE  * •/ 

/•  TARGET  PPCGPAM.  */ 

-/*~tHPCUGHfiUT  THE  CC^PSNTS  tq  THIS  QCU  T I N E 7"C  ER  T MN  ME  T A-VAP  I ABLES  */ 
/•  WILL  BE  US60  TO  DESCRIBE  THF  CCUE  CENEPATEO.  THESE  MFT A—  */ 

/•  VARIABLES.  DESCRIBED  0 ELCW , ALWAYS  SECIN  WITH  THE  CHARACTER  */ 

/•  *#*.  __  •/ 

OCCL  RFILESUEF  CHAP  I *Ax.„L..NAPE  ) VARYING; 

✓ « This  I_S^  cTp. FILENAME  with  TRAILING  PLANKS  OROPPEO.  jhe  •/ 

/•  suffix  '•f  rs*  rp  • t • or  • u • indicates  that  this  is  a source  •/ 

/•  e.C.  •SAtEOECKS*  • I N E VNu • 'PASTERS*  *MASTERT*.  */ 

OOCL  kFILlNamf  Chap ( *ax_l_NAmE  ) VARYING; 

/*  THIS  IS  THC  riLFNAvc  wfTHcUT  THE  SUFFIX.  _ •/ 

/*  e.G.  * $ ALPOcCK*  • I N’VfN  • *maSTER*.  ' ' *•/ 

OJCL  EC NAME  CHA® (LEN^OtC T^FNTRY I VARYING  EXT;  _ _ 

/+  THlj'is  THE  R FCDP  C * NAME  ~Fp  r m FIR  .R  ECNAME  ~wTt~H  fa  AILING  •/ 

/-  PLANKS  OPPPMEO.  Pr$SI«UY  RccpixEC  WITH  •CLIU*  CP  ‘NEW.*.  •/ 

/*  £.0.  * SALcpf  C#  ’OLO.INVEN*  • NEW.  INVFN  * • - */ 

OGCL  XHF.Cii&~  CHAW  ft  cr.C'IC  7.H.VT9Y)  VARYING;  _ 

/*  THIS  IS  LIKE  *o  = c\A‘*E  HUT  has  *C LC_*  AND  *NEW_*  INSTEAC  " */ 

/*_yF  ANO  1 N F w » * . THIS  TS  USEC  FCR  LAPFLS  IN  THE */_ 

/•  target  prccpam.  * ' •/ 

/•  E.G.  • S AL tc  FC  * 'CLO.irVFN*  •NEw^INVEN*  */ 

OCCL  4PtCsrEN  CHAP (L EN^OICT.PNTOY » VARYING? 

/*  THIS  IS  THF  ••STEM"  np  tmc  RCCTRP  nave,  WlTHCUT  ANY  PREFIX.  */ 

/•  USF.O  IN  REFERRING  TO  PCIMTgRS  IN  THE  TARGET  PROGRAM.  •/ 

__  /*  F.G.  • S AL  E^Ef  * * INVFN  * . */_ 

ilti  LEN_REC'srJ  INS  FIXED; 

ALLN.KECSTP  I \*G«  ? ♦ L = N_0  I C T _CN  TP  Y ; 

CCCL  *MbCSTh IMG  CH AM L EM.R EC S TRI  NG  I VARYING  FXT; 

/*  THIS  A, A v F S THE  STRING  VApjaDLS  *INTC»  WHICH  WE  READ  •/ 

/•*  ANn  *FrfOH«  WHICH  wE  WRITE  IN  IHP  TAPCET  PpCGKAM.  •/ 

, /^_ECK«60  hY  SUFFIXING  *oECPAJ»  WITH  *_<«.  _ ♦/ 

/*  e Ig.  * 5 ^ L ^ uE C „ S * rP LH^I f Vc \_ S ’ "•  N 6w“  I>TvEn“T*T  ’ 3S$m<  •/ 

COCL  *»KEYNi.lE  CHAW  (VAX. L^NAMr)  VAC  Y INC; 

/•  THIS  IS  TWC  NAME  PF  the  KFY  fjElO  CE  a RECORO.  USED  FOR  */ 

/•  FtAHfNC  'EYFQ  SCCUENTial  FlL.ES.  CH^AINEC  PY  REMOVING  •/ 

/•  Tr  AILING  BLANKS  FPC."  F LOw  I A«,F  EC . K E Y NAME  . ^ 

-CCL  SUP  SCk  I p T— S T ACK  I M AX-.DC  PTH^S  T Af  K.  | ChAR(3)  EXT; 

OCL  SUB SC N I PT_ STACK JTCP  PIN  F I X F C 1 1 5 ) f X T ; 

DLL  NSTR  HIN  FIXED!  15)  EXT; 

CCL  Mrt_PT»  POINTFR  EXT ; 

l _ F fR.Pfv  •FLNNTAP.PgC^PrR; _ 
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#FUESJFF*C«Pr,,Le(FrR  .Ff(  ENA« 

*F  RENAME*  SURSTd  <«F  UESUFF.l  , 
0/*  A^SCnAAF  CHMCS  DIRECTLY  FROM  F 

y^ccnavf-chptpl  bi ftp .rfcnawf  ) 

0/*_GFT  THE  STCM  PP  AHf TN A*E « . 

t F*  l" * HOfeXI  *R EC  VAHE  , • I’LC  . • » 
them  iRFCS^n-subSTR  cuarcNAME 
FUSE  Ir  l*lNr*FX(«FFr.\AMF,  «MFW 
then  irecstfm* sissr® ure 

ELSE  /*  NT  ORFF  IX  •/ 

»tfFCSTEH»«PcCNA“E; 

0/*  FPKM  ARcCeAR 
/•  C.G.  ' SALEr  FC • _ — >_ 

/•  •NE*.  UtVf.N*  ;> 

/•  •PLO.I^VFM*  — > 

le  l*  INOE XI YRFCN amf ^ • CLO • ' I 

THE  * •RFCRA7,»,PLn.*  j LjiiJCST 

ELSE  IF  l*lNDEX'(»fFECNAMc,«NeV 
TnFN  ARECRAO  ■•NFW.«  ||  • 

ELSE  /«  NO  PPFFtX  */ 

•RECRARsYQECSTE*; 

0/*  F CRH  ARECSTRIMG. 

<MtCS TR  |NG» X_a ECJ? ap  II  • _S* : 

"C/^  FCRM  X kT v"u  am c\ 

YKEYNAVC-CHPTF.LP  ( FTP.  .KEYNAME  ) 
PL  T SKIP  Li STI • ***«•*•«••*••**»*• 
per  jk/p  Lfsn#*  ^FNfrcn  CAtten  • 
pli  skip  list i * **•*•*•*••••*•*•»• 

_ PLiSTRa/uc;  •; 

CALL  W<PLU0LISTR,»PLI  = X»  I; 

-/*  RJA.JLM  TP  LA^CL  WHICH  HANPLFS 
0 if  I 1 C"»OPF*  *RD*  ) C (PPG-'SM 

o ic  1 1 L’-’PPf  »•*''•  j c (r^r^s'i 

0 IF  MOHC-r*  •<«rf  | r. 

C I F_  1 1 c y nt'  r * ' W w •_)  _J  CPC**  S»  ) 

0 IF*  l I QyOliE  * *3  -i«*i  f.  I C®  C*  M • I 

0/*  IF  M«)  C/.SF  APPLIES,  then  SYSTE 
CALL  SYjFPP  f •OrvtPCOs  UNKKCW 

retu*.*;  /•  Nnr  needed,  as  svs 

ICASEl: 

-r  l ' _I.H  I 5 SECTION  WRt  Tg  S-CC.CE -FCR 

/* 

/*  

-/•  riLF  PLIEX  GFTS: 

0/»  V*  j_*wF  ILESUFF'*:  . . 

/»  HEAD  Til  EC  ,,*B  I lESHPF'M  I N T C I 

„-J*  J. r Lfc  _p  L 1 rv_r--c_TS : 

0/*  u.-i  cUOFILM'MC  ILESLFF"!  goto 
-PUSTR**  i.xO.'  ft  *filESuff  If 

Call  v<rpl  i i pi  i str  . • pi  ic x • i : 

OPLISTh** k?-C  PILE!'  II  *F  IL6SUFF 
Cai  L M'Pi  l(°LiSTP,  *P|.  IFY»  ); 

OIF  IFTA.PA<.*cr*  l >_  ThFJL  C.AJ..L  PE*' 'Ef 
0PL1STk**CN  FNCFtlF  I*  II  *FILFSUF 

CALL  WPPL  l ( PL  1 S T5  * * PL  10.N  \)  • 

JCCTC  F IN  I SHE C # 

1C  A SE  2 : ..  . . 

-/•  THIS  SECTION  WRITES  CCOc  FQP 
/• 

/• 

-/  • F ILC  PLlC  x PFTS:. 

0/»  $-0_"tFTLFS(/FFw: 

/»  . k?AU  h iLSt -if^IlES'JFF'MlMTCI." 


f # ; 

LENGTH! AF ILFSUFFl-llV 

T 0 » te ITN  TRAILING  BLANKS 


•5,LENGTH(XRECNAME)-4) ; 

.»  ) 

CNAY E#5r LENGTH (ARECNAMEI- 


_ ‘SALEPEC* 
•NEW. I N VEN* 
...•CLO^I^VFN1^ 

C.MJ 

. * I 

RECSTEP? 


0R0PP60. •/ 


THIS  particular  TYPE  Cf 
r.  I K c Y p C * C ) TmC\  C(]Tp  CA 

e ikeyfc*i j then  goto  ca 

S (KEvcC*l)  TWC\  GOTO  ca 
Then  GCTC  CASEA; 

K (XcYFC*!!  THEN  goto  CA 
p EPPCR 

n rr«H  cf  flcnt ap.rec*  I : 
ERP  will  halt  FYECUriCN 

KHCGE*»?Ci 

Cu  G*  * S • 

LNKEY60  ... 


"•PECSTP  ING*» » J 


FLCwTAfl.R 

sei  ; 

SF2 ; 

SE  3 ; 


It  J)  INTC  (•  II  *R  EC  S TP  f nG  II  »J 
ALe^PACx  INC; 

f ll  • i CCTC  tf  ini sh: • j 


iCHcrE-'Po* 

_GF.C«_!_SJ 

KEYFC 


ARECSTp lNGn ) i 


/•  IF  UENAMF’*. "•KEYNAME"  * PO  I N T EP  . " *o  EC  S T EM* 

/»  THEN  CCTo  t"«»FCP*o*_cNn: 

/•  IF  "tfF  lLENAMe"."*KEYNAMfJ^  < PO  I N T E R . »•  **  FC  S T EM« 

/•  ' then  uo; 

/•  WRITE  FILFI  "X  F ILFNAM£»T  ) F PCM  I • «R  EC  S TR  INC**  I ; 

7*  JPTTT«  D_  ••  & FI  ii  5 ufWi  " 

/•  6*05 

/*  CALL  *\CTFOUNI><  •"•TlLESUFF"'*  >S 
/•  $"*wecpa«"_fno: 

-/•  FILE  PLICN  GETS:  ' 

_/*_  ON 6«%J  r CLf < "*Ff  LE  S UFF"  t call  tNCrFCUKCC  *««f  ilfsuff**  » ; 

-P'lTS t k*  • Sk  j"*TT  #F  II  eSl'FF  1 I • : • ; 

CALL  W^LIPLISTR.'PLUXH; 

QPL ISTR»» *6«0  F l LE ( * II  AFIL6SUFF  II  M INTC  ('  II  *RECS  TO  ING  II 

CALL  WM»L  l(°L  ISTm  ,*rL  IFX*  

Q l F ( f TR . P AC*  CO* l I THrK  CALL  GENF P A T E_LNP AC K I NG 5 

PPL  1 S T**x  * IF  • II  *c  I Lf NAME  II  «.» [I  *KFYKA*F  I l_  •__*  POINTER.  1 | 

«plf£st  e** 'IT  ' "*tmf n c.nfo  %•  IT  *p'EceA»  ||  '•.end;*: 

CALL  *RPLl  (PLISTP , • PL l=X*  ) : 

OPL  1ST  h»  • I F • II  *F!IENA"F  I)  • TlAKFYKAPE  ||  • < POINTER.*  || 

XP.  ECS T Ew  ||  • TMFK  00:  *5 _ _ 

CALL  wPPLII PLISTPf'PLIEX* I ; 

J>  PI  l S T « * • »*  l T E c l LF_(  • I | *FILENAMF  II  *T)  FPCMl*  I |_*  REC_S  T R I N. G _l 
CALI  "WPPLII  Pl  fSTR,  • PL  FFXM  5 

OPUS  rka'GuP  ||  XFILESUFFJI  _ 

CALL  WFPLI<PLISTP#*PLIFX« »5 

OPL  1 S T*<s*  Ff.o:  • : 

CALI  wAPL l ( PL l S To  * • PL  LEX • I ; ~~  ' " 

OPL  i S Tw * • call  tMr.TFnij^nc » » « ||  xfilESLFf  II  •»•):•: 

cal  l «»p  PL  l ( °L  l S TP  , • pl  l F X • I : 

OPLIST****'  II  a^fcpap  II  *.FNC:*_:__ 

CALL  -FPL  KPLISTC  ,'PLIFX*  ); 

OPL  1ST***  0.»  E\nclLc(*  II  XFILESUFF  II 

• ) call  iNOTrruNOt  •••II 

*c  ll  FSUF  F II  •••);»; 

CALL  wKPLlin'l  Sfo  , • PL  ION  • ) ; 

OGCTC  F IN  IShFC  J __ 

1CASF  3 s 

-/•  this  SECTION  WRITES  CCCE  FCP_  irPCCF^'PO* 

/*  .........  CFG**  I • 

/* xFYEO (NECESSAP  II  Y| 

"-/•  FILE  PLIEy  G^TS: 

0/*  RcAO  FILE! "*F ILFSUFF")  I MC  C " *R  ECS  TR  ING** ) 

/•  K6V(  POINTER. "XPECST6M"  I ; 

-/•  FILE  PLI«1N  GETS:  . 

0/*  ZH  *6Y("*r  IL6SUFF")  CALL  INC  TF  CUNC I • " *F  I LE  SLFF»*  • I • 
-PLlST*»*KEAr  FILE!*  I I »FILESIjFF  II  •)  INTC_(*JJ. 

• PECSTFINC  rrrl  ”xEY(PCiNTFR.  • *lV 

EC  S T E M ||  •):•;_ 

CALL  WPPIIIPLISTC,*PLIEX»); 

OIF  (FT® .P ACKEO*ll  TFFV  CALL  GFNFP AT E.UNP AC* ING?  _ _ 

OPLLSTk*»ON  KcYC  II  *FILESUFC  || 

_ *)  CALL  tNQTFntiNCC  « » * II  PfllFSLFF  ||  •••);•; 

CALL  VPpLlfPLlSTR.'PLlUN* ): 

CGCTCj  F INI  SHFO:  

ICASEA: 

-/*  THIS  SECTION  write_s_ccce  .fcp ICHCCE*  • WP.  • „ _ 

/•  ' CPC*»  s» 

/•  KFYFC  OR  LNKEYEC  


-/•  FILE  PLIFX  C6TS: 

0/*  - M T E r ILc  I M*»F  ILFSIIFF*’!  pcnp  (•••OECSTP  INC"  I 5 

-IF  IFT^.PACKFO.  1 ) THEN  CAli  C,?NF0ATF. PACK  INC; 

OPLISro**  wRI  r?  ‘-'iLPI*  If  *F  II  ESUFF  ||"*|  FPC^  (*  ||  APECSTOfN'C  f 


(NECESSAP II Y> 


•/ 

*/ 


I , 
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CALL  WR?Ll(PLlSTB,M»LlEXMj 

OCCTC  FtNISHFO;'  ' 

ICASE5:  __  

-/*  THIS  SECTION  WRITES  CCCF  FOR  !CPCCE**RW» 

/* DF  G » * I 1 

/•  KFYEO  (NECESS Aft ILY ) 

-/*  FILE  PL16*  GETS:  . 

0/*  REWRITE  S1  LF("«F  ILFSUFF")  F ROW  C "HP  EC  STP.  INC") 

/*  <F.y  l PC  l NT  F P\  '*  SCSI  ) l _ __ 

-IF  (FT*  .PAC<EO«l  ) THEN  CALL  GF N?  P AT  E .P  AC K IN(f;  ” 

_OPL  IS  TR»2.HFV^»  Tc  MLFIJ  II  * F I J.F  5LFF  }[ 

• f F P('M  ( • I I "<f P ECSTMNG  "l  I 

•I  KFY  ( POINTER.  •_  ||_F*>FCSTfP  ||  Mj1?  

CALL  wRPL  l( PL  isro # «PL  IFX« ) ; 

-FINISFFO:  

PLl S TP** EN‘): • r 

CALL  w^PLUPLlSTPt'PLlEXJl* 

PUT  SIMM  EXIT  GFNIOCC  ) ( SK  T P , A ) ; 

turn;  . . _ _ 

IGthfcnATE.UNPACK ING:  POCC: 

/•  THIS  l*  rt-c  5UOC0VISCRY  pcCCFCUPF  FCP  CE^E«ATrNG  UNPACKING 
/*  lUST^LCT luNS. 

CCL  I PIN  F r X F c I 1 5 ) ; 

CALL  IN  Ft IAL IZC.SUPSCP  TP T. STACK ; 

KSTP*C:  /•  TP  l l ^ WHICH  S’J0STPuCTLR6  WE'P?  LOCKING  at. 

PLISTm*  ; /-  INITIALIZE  etFFER  PCINTEP.  •/ 

CALL  «"°Ll (PLlSTo ,» PL ICX« l; 

3u  1*1  TC  FTC  JPr.As  f TY; 

_CALL  -jmpaCK  (l>;  / ■ NFXT.INCEX  TC  USE  IS  l.  */ 

f NO ; 

RETURN;  _ 

ENG;  /•  Gc\FC  ATE.UNPACK  [NG  •/ 

LGc‘ t-ATE. Packing:  PRCC; 

/*  Til  r IS  THF  SUPERVISORY  PRCCECtRE  FCF  GENERATING  CCOE  TO  PACK 

/*_GUTHjT  .RFC^.NS. 

CCL  l * PIN  F~TXE>(  15  1; 

CALL  l.iIT  IAL  IZE.$U«SCa  IPT^STACK  J .......  ....  

N S T m a o ; 

/•  G5T.ERATL  rmE  TC  INITIALIZE  OLTPUT  STRING.  . . 

PL iSTRatffiECSTB  IMG  I I 



Call  w a p l 1 1 p l I S t r , • p l IF x • ) ; 

/ * CALl  PACK  cn?  EACH  *e*PFft  CF  THE  RECC°0.  . 

oc  i * i tp  »ccopc_ap  r ty; 

CALL  paCKCU;  /•  r.cxT_INCEX  TC  LSE  IS  1.  */ 

c\o; 

RE  TUB  N;  _ 

ENU  ; /•  ceveratf_pack  IMG  •/ 

-IM  T l al  IZE^SURSC'T  IPT.ST  ACk:  prCC  ; _ 

/•  internal  ti  GFNirm. 

/•  This  PF.JCEUUPF  INITIALIZES  THE  Sue  SCF  I P T_$  T ir  k ; CALLEO  BY: 

/•  GENERATE. PACKING 

/l GF\F*  ATT_y Nf.A C Kj  N Q . 

scaSCR  i p T— s r ack_  rrr=o ; 

RETURN;  

ENC;  /•  IM  T T AL  T ZP.SUPSCR  fPT, STACK  •/ 

ENO;  /•  GF’i  I PC0  •/  .... . „ 
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♦process  ( •Nsr,Hicf;a,s*rc\«5£T/  u_ 

G fc  h F S E T : P°CC ( FLOW.PTP ) ; ' 

■CUCL  MAX^LTN.OKAf-E  .FJJ»50.S 

*MAA_IcN_CNAHc-32  ; 

/» rnf s ppol 5?y»E_® r s ft s swrroes  at  bnc  cf  each  r bad  cyct  £_•/. 

OCL  FL0W_PT9  POINTERS 

OCL  TE*R_2cRC  CFAKIA)  VAR;  

OCL  ChPTRLD  RNTPY  (CHAR  t * ))  PETURNSCCHAP  IMAX_LEK_CNA*E )VAR ) ; 

C CL  1 FLOi/rAej»S FT  “AS6n(P)t ..  „ __ 

2 f.CDF*  FIXED  “IN* 

2 TYPE  CH  A Jj  4Jl 


2 NAM?  CH  AP  ( *AX_LEN'_CNAMf  ) ; 

p*flGn„°TP; 

IF  NAME *' PS  TACK • THEN  /*  THIS  IS  CM  V RLNTTmp  V AR I a dL  E THAT  IS 
FUcU  c*  IN  c A THEP  Than  6 I T ( l ) ; IT  IS  INDEX  TC  “UNTILE  STACX  FOR 

REPLACEMENT  */ 

l£MP_2rp? » >0* ; XL  5f  . t E * 3_  £[  - r = • • •c*JLB  • S 

CALL  W^f'L  I (CH^rpLOC  VA^F  ) I I 1 * • I I T £ HP_  70F  C I I * : * * * PL  IE X • ) ; 

EN0;  _.  _ _ 

•PKOCESSI  •NST,fI»GE*lTEXT*  I ; ....... 

GENT  CAT:  PPnC(R); 

OCL  .1  F H: W T * H _ T ? X r _ g a .S f C 1/ J.  C V>  l£& „ T f X T_o  I P ) . 

2 NjUc*  FIXED  HIM, 

2 type  CMF3(4|v  /•  'TEXT*.  •/  ...  ....  . . 

?.  LCN.TMT  F Ixeo  f.  i\  # 

2 °L 1_S  f R CHAPIN  REFER (LFN. TEXT) ) ; 


OCL  ? POINTER; 

FLGwTA0_TFXT_»TP*P; 

CALL  *RPL  l (PI  l_STF  # «PLIEX'  I ; 
ENOJ 


f*«fc  * 


^ t , 


4 


s 


i 
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• Cc * S'PfJ ST  . M A Ck  0 , A * C I m £ L o • ) ; 

GlMl-LU:PFOH  TAa_FiO_PTo  ) ; > 

/•  GE.'iE^ATc  ASSIGNMENT  STATEMENTS  FCP  IMPLICIT  F I ELG  ASSOC  I A T ICN$  * */ 

CE  Cl  An  £ TA3.Fin.PTo  PCIMTER; • 

t INCLUDE  IKCLMICniCTM  "• 

CCL  CHPlKlo  FNT»  Y(CHAM  *)  ) PETUPNSICUPt  IEK.OICT. ENTRY)  VAR)  ; 

CC l ~i  ~r l L « I*A e . F t F l n SASFCCFLGWTAB.F  ielc.ptrT, 

2 NODE  A e l XED  P.  J N * • 

2 VOOE.TvPE  CHAP |4) 

2 TCT.Ficip  CHAPtlEN.OICT.EKTRV ) , _ 

~2  SKCE.F  rcio  CHART  lEN.ClCT. ENTRY) 

__F  LC’VTAB.F  IEIO.pT  o a TAft.FLD.PT*; ” 

IF  >.C(ic.rY.°f-.*'»  FlOf  »C  Vn'CF.TrP'g  ThF  N 

CALL  SVSf  PP|*GIMFtC!  TYPF  crcfs  • I INCCE.TYPE  ) ; 

ELSE  CALL  V4=.Pli(CHPT?.u:(  TGT.F  IELC)  | | •«•  | |CHPTRlB<S4CE.FJ6tC)  I I*  :•# 
♦ PC  LEX*  1 ; 

RCTURN; 

EN Q G IMF  CCS 

•p*OCESS(  •NST,Mac»«'»,N«G40CCP* ) ; _ . . _ 

GMLCLJ: P*CC (PSSC.pTK I ; 

/*  this  P°  OC  EGiio  C GENERATES  ThE  PRCCECUPE  STATEMENT  FGP  t MQCULE.  •/ 
CCL  PjbG.PTo  PG!NTE«; 

CCL  PW'C_5TWT rHAP.J90)^ 

CCL  L FLL;WTAB_MnC  «AS>9  (FlOW_PTR)t 

2 NODE*  FIXGC  *4  IN, _ 

2 Ncrr.T ypp  gha»  ('•)*«’ 

2 "CO’JLF-MMF  Ch6»(l  0): _ 

FLCfc.Pr^PjSC.PTR  ; 

IF  NwCE.TYPF~*»*  hCOL  * then  call  SYSERC  ( TMPCCC:  faC  CCQE  : * I 1 NCOE.TYPE  )j 

E LSc 

DC;  _ __  

PP'lC.S  TMT  * • • | | vrn'IL  F.N  Amp  j | • : PPCC  CPT  ICNS  (MAIN);*  8 

MU  l TE  _FlLr  (TLIOCU  FPCM t PPTC.S TM T ) ; _ _ 

ENC; 

RETLRn; 

“eng"  c.mooco; 


t *<*.jm*s 


/ 
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•PPCCfSS  < »NST  ."*0*0.  SM*  ( 2 • 72 1 1 ) ,n*GPLICCL  • ) ; 

CPLIOti:  P«nc:  __ 

/*  PLICCL  CcNfRATES  A P L l CEC  L ARAM  CN  ECr  f V6P  Y CCl-PRCTC  Of CLAP  AT JCN 

»/ t X L L F NC,TH_KF  Y.N  t HE  _F  1 x EC] 

SOCL  HAX.LCfi^CNH  p'lXEO; 

1CCL  MAXD.CPN-DAS  f I x eh ; 

tCCL  MAX.LfcN.FORfcACH  FlXfCT 

SMAX.LFN^QNM  »32;  

xhax*_CQnL'as*30  ; 

XHAX^LfN_FC-PEACHxi3; 

*LEM?TH_K5Y_NA«E*10 ; 

CCL  LINE  CHAP  (2  94  1 VAR;  

/*  LINE  IS  FOUl  VALENT  T O a PUNCHEC  CAPO  . IT  REPRESENTS  A PL  l OCL  */ 

OCL  SIGNAL  PIT! 1)5  _ __  

/"  SlGNAL*'0'H  INCICATFS  THAT  there  ARP  NC  UPDATE  flLES  «/ 

/»  CN_  Th  1 S _f  I L E THE  I I NE  IS  WRITTEN  • / 

CCL  null  built  in; 

O _ CCL  1 F lEL«)_OCL_F»OtP  PASFC  (P), 

/•  this  IS  The  PQCTC.tydf  CcCLARATICN  CF  a FTFLO  GR  INTERIM  •/ 

Z Type  CHAR  (2 ) . ./*  ?FP.  FOR  FIELC  CR  'IN'  FOR  INTER!"  */ 


2 FIELO.LEVFL  FIXES  (3)  CEC 
2 fiplo^na^f  char  (l  f.ncth.ke 
2 MAX.agPfTinCN  F'XES  CEC  ( 
2 f iclt.typp  Char i i ) , 

?_  F f EL  )_L  t 'i_  T YPE_CH  A®  ( l ) 

2 VAX^LCV  PtXFO  (5*0) "tEC IR 
2 MJN.LCV  FIxFO  15,0)  F f C I R 
CCL  l FfLF_CCL.PRCT^  PASFC 

/*  this  is  thc  prctoyph  c 

2 T Y°P  CHAPI2I*  /•  •PL* 

2 FRF. LEVEL  FIXED  13)  PFC  , 

2 r!LE_NAMc’  Chap"  (LENGTH. KF 

2 P!Le_FLC»  ChA°il>f 

2 F IlE.PPr,  CHAR  ( l ) ; 

OCL  i DCCr'°P.OC  L.PPOTO  pa<E 
/•  THIS  IS  THC  PRCTCTYPC  C 

Entry  •/ 

2 type  Chap (2  I # /•  • °C • 

2 - fC^R'^LFVFL  El^fc  (3,0 
2 3 f C0°  D.NA  vc  Chap (VAX. LfN. 
2 *FCnPD_LFNG Tm^Tycf  CHAP  (I 
2 » FCn3  n~L  F f.C  Th”  FIXED  C F C ( 5 

2__lR  F_P  EC  NA  HP  f.HAPHAX  Lf^ 

oc~l  i 'oclIp-ctp'rasfo  T?) 

/«  rnrs  cfnehal  cecl ap at icn 

2 TVPC  c h a J (2 ) ,/*  • FP • FCP 

*RR*  fcr 

• f.?'  F c R 

2_L  = vet_F  jxep  _(  3fO_^F£  » 

2 \AME  Chao (i  enctf.rfy.nare 
2 v- A E Pf  T l T IH?J  fIxEC^TECI 
OCL  Cu..nAS(  " AX  V.CCNTAS ) Chap(LF 
✓ -TARL  r 'IF  AS^FPriCNS  USING  C 
CCL  ACliNOAS  fjxcq  ON  EXT; 

CLUOj;  _H.CL  I \L0SYSFOfJ  ) 5 

OCL  C wp  f JL  ''  ENT3Y  (Cha-3  ( *)  ) P 
CtL  fc#ne  ILF.OCLTAO  Mr(l)!NI 
f M*  f_I  NT-IP  I v H f T (t  ) IMTCl'8) 

1 00 T A6  ( ** ) C TL  FXT, 

2 LOC  FIXED  RIM, 

_ 2 _OC_Ll  ('  P_Y.AR._C  M_A  n ( *AX_Lf  N_FfPF 
~xl  COPS  - I XE'"  "IN  EXT: 

OCL  wr'?c l FNTPY(crxrn  ocr.rn 


y.na“6 ) , 

3), 


ECLAPATICN  CF  A FILE  CR  A REPORT  •/ 
eCR  FILE  CECLAPATION  •/ 


C IP)  r 

cCLARATICK  CF  A flECCPC  OR  A REPORT 

FC«“ECCPC "s"fT ing”  c e clTp a r frjN  *7 
CEC imal  * 

CM*)  • 

) • 


IS  USED  F^e  S TF  IJC  TU°  F 5 -/ 

FILE  NAVE  AT  TCP  LEV FL  CF  STPUCTUPE; 
R6CCFC  CCL  AT  2rn  L F VEL  CF  STPUCTUPg 
GPCUP  CCL  IN  THE  STPUCTUPE  */ 


NGTH.kf y_N AVf ) VAR  EXT; 
CNDIT  ICNAL  FACTIONS*/ 


6 T'JR*:S  (CHAP  (MAX.LEN.QN")  VAR  ) ; 
T ( • 0 • F ) ; 


to l * I v<o i ! 


/ 
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/•  UC.LT  au  15  The  INPUT  FILE  r>N  RHICN  TFE  PFCTO.CCL  APE  STORED  *t 

OCPtM  FILE  L'*CL  TAPI  INPUT  RFCCFC  SFOLI  

0 ON  E'lnFIuECCOLTAA)  ENDF  ILt.UCLTAP*' l 'f; 

-/-  IM TX4 ll r THctr-  arf  nT:  update  files  -/ 

SluNAU»'0'P; 

-/*  generate  pcl  keynupo  ; •/ _ . _ 

line**  pci  •; 

Call  WPOCL(OtLINE)  i _ 

0 read  riLEirCLTAPI  SETIPI; 

_0 IJ  1 NHILF  U^F  NOFILE  rCLTAB): 

Cali  fpli"cl; 

_ REAP  FILE(CCLTa6ISSTIP)S 

/•  REAO  Trie  PPDTD  DC  L AND  CALL  fPLICCL  UNTIL  THE  END  OF  CCL  TAB  •/ 

. End;  _ 

0 IF  S IDN.U* * l • e then 

-JDO; 

/’SIGNAL  F*3®  »RESENCC  OP  I/O  MLES*/ 

/•  CECLAFF  Nc 'W  LIKE  OLO...*/ 

L I N E * ' \ E W L I K«=  OLO;  • ; 

. CALL  K^wJCLI  liLl'iE)  i . . 


ENO; 

ELSE  Call  wkoCICO*'!  fixfh  2In;«); 

IF  USzFC'KlI  THFN  /*  *JS?0  TFE  'R.-PLACE*  FCM  GENERATE  CCLS  •/ 

00; 

c**ll  to.  'ccl*  i ; 

c«ll  wFortio,  • waspepl  °mn  initi  « •crreff  • ) ; 

CALL  or  on  CO.'  <*.1  R 5 FPL  n I T I III  N I T ( ' ' C ' • R I . • ) ; 

CALL  WcCCL (C»  * » S TaCK ( «0  I C*  *P ( 1 C » VAR f * ) 5 
CALL  wsQCl  10*  * *STAC*  FtxFO  C I N IMT(fl|{«){ 

ENOS 

-/*  CCL  «S>.lPCTF»)*  AAC  »Nf  T_SElECTFC*_  RUw-T  ME  VaR  l a r L £ s _•/ 

CALL  ~ir  OCL  10#  • OCL  SEl.FfTsC  P 1 T ( L f T * I T ( ' • l • ' E I ; • ) ; 

CALL  W*OCLfOr  'DCL  NTT_SFL  ECTrr  eiT(l>  (M  T ( • ' CM  el  5 ' I ; 

-/’GCNEPATt  CCL  FC3  Ary  CCNOITICNAL  FCN  USEC  •/ 

occ  i* i r r *syspcks 

IF  C'JNOFd)  c UScFCNU)  ThEN  ' 

CALL  wanr.UQt«nCL  _1  ]J_CH  P T EJ.  p < S_Y  S FCM  Mil  1 '.CO^lc^EO  31TI  1 ) : J_)  ; 

cNO ; * ' ' " . * 

-/•GENERATE  OCL  tp  ALL  CCM>  I T I CN Al - A $ S S* T ICN S CCPPLEMCN  FLAG*/ 

0-J  1*1  TO  ’COMPASS 

CALL  v<r<CCLC3f 'OCL  • I ICONOaS  II)  I I •.CC’PLE  TfO  9 1 T III  I N I T ( • • C • • e > ; • ) 5 

cNo; 

-/•GENERATE  CCL  FCP  "PC'*  (WFCPEACFW)  VAP  IA9LFS  •/ 

0 ~ 00" I *"i  fn  tficnps; 

CALL  W°  OCL ( 0 • 'CCL  * I I CC_LCCP_VAM  I ) I | • FIXEC  8 ( N S ' ) • 

ENOS 


-/•  GENERAT 
• L EN  ' 

0 Call 
' -ClCSc  pile 
IFPl i DCl  : 

0 


PPf SSION 
CCL  MU5 
CC L JUNE 
/*  TFMPCft; 


: CECLAoa 
, •POtNTc 
,3L  1 ir>L_L_ 
■pl'inc'i > ; 
ppoc  : 

OCL 

I STRING! 

' * STp  ING 
IT-  Lf  Ng«/ 
sfr  I‘IG  0 
/*  S TF  I\ 
0 c A OFC 

( 1 3 ) 
;map  (i3) 

IV  S To  I flG 
[ F lie 


T I CM  S OP  •SPFCML*  N A * C S ; ! .E  • •CHOICE*.  ’EXIST*, 
R*,  AND  'SUBSET*  CSCLARATICNS  •/ 


2 

2 


, STRING?)  CHAFI32)  VAQ  STATIC, 

l AN C STP.  ING2  APE  USFC  AS  TEMPORARY  SUBSTRINGS  OF 

hSpc’57  s fa  t r C; 

C is  a SUa STR  ! * G _CF  LINE  WHICH  WILL  06  THE  STRING 
IVAL  .NUMBER  */ 

I N I T ( ( 1 5 ) * S • ) j 

vap  static: 

FCR  • IV  TCP  I m • OCL  • / 

I PRC  rC*  T YP 6* * F L * THEN 


L l N E =F l L E_ 
CALL  WKCCi 


STP  IN 
: C L_RRCTr 

icTl  INc ) 
r-K 

FlSF 

if  rc 

On 


Jr  F !l F_DCL_FRCTC.F I le.FLCW* * I ' THEN 
STR I MG l«*  INPUT  *: 

ELSE 

!£_-fJ  LE.nCL  TC  .F  f L E„  FI  CW_=  'C*  7 MEN 

string!**  output  *; 

ELSE 

S T°  I *'G  l - • UPDATE 

! F F (Lc.or.L.PFr  TC.F  1 !.E_CPG*  * s*  THEN 
STRING?*'  PKCCPU  S EC L 

_EJL  S_p 

02=  * <EYEO  C l 5 FC  f fnv(IKCExEC)  *: 

• FILE.NAVFI  | • FILP'I  ISTRJNGII  ISTRIMG2I |*,«; 


L_P3QTC, TYRE* «PC  ' T ME  \ 

IF  ^FCr®  O^nr.L.PRCTG  . PFCCRn^L  E\CTM.TYPF=  *v*  tmfn 
S To ING2=  * VAR  • ; 

ELSE  


stc  : %'G2* j of r • j i c m p t «?  l ° ( of  p e c >\  am  r. ) ; 

P'JY  STP  ING(  STP  r.TIEC  I T ( RFCGPO  PCI  PRCTO. RECORD  LENGTH)  <, 
(F( 5) ) : 4 

L INC  “ChpTkLR  ( RPCCRO_OCl  PRCTO  .PFCGF  0 r,AME)ll»  CM ac ( ' |l S TR  INC | | • ) • 

__J  1ST  - 1-iG?  I | l_,±: ~ 

CALL  nr  f.CL  ( J , L tsc  I : 

_ CNO; _ <, 

0 p LSE 

IF  SIGNAL  * *0*RCnCl_rPCTC.TYPE  = *FP » CCCL_PRCTn.lEVEL*2  THEN  3 
/ *c 1 3 S T STRUCTURE  PCP  AN  I/C  FILE*/ 


► ■ 


J 


/•  there  are  upoAre  filfs  */ 

SIONAL** 1*6; 
L !NF-»OlC, • ; 

s 

CALL  WB CCL ( l tL INF  1 s 
L I N*C *OC  L PPprc.NAMgJ  1 % » ; 

» ' • • 
1 —> 

CALL  HHCCl 12  *L I NE I ; 

EN05 

ELSE 

_ /•  AIL  CTHFB  TYFFS  •/ 

OH  5 

IF  OCL  PHOTO.  TYP6-**fO»  C CCL.PPOTn  . TYPE-.*  * IN*  THEN 

* 

3 

4 

f 

1 

/•PROCESS  ALL  CTHEft  TvPrS  eUT  F I EL  PS  C INTPPlMS  */ 

CC; 

IF  OCL. PROTO. *AX„PrP«=T  IT  JP.N>C  THEN 

PUT  ST3 l NO ( S TP  INC?  ) E OlT (•(•,  CC l_PPC TC .* A X_« 6 PE T I7IQN *•)•  > _ 

(A#F<  3 I • A l ; 

ELSE  STRING 2**'j 

— 

0 

CALL  w=na.(nrL_PBr)TC. LEVEL. nCL.oBOTn. KAK6I  1 SfMsr.2  1 1 • . • I ; 

ENO; 

els? 

DO;  _ _ 

/•  TYP^aFO  Op  TYP6*IN*/ 

_ if  f i cLr»_nr.i.o°cTp.  Ax_ocPFr  r t icn>c  then 

5 

6 _ 

- 

PUT  srRf»'<:(iTH  ING2)  6 0 I T I ' I • . F I E ir_CC  L.  br  C T C . M ax  .PEP  E T l T I CN  • * )•  1 

( * , F < 1 ) f A ) ; . ...  . 

CL  Sc  S T P I NO  2 * • • ; 

L lNc*OCL^»!90Tn.NANP  | 1$TP  ING2;  

IF  F f ^l  0.  TYPE  *'\*  rHC‘i  STPfNCl«>  P IC  • • • 1 1 

SUdSTR(?;.ms,l,e!FL5  QC  L„FCCTC  ,M  ftx^LEM  ) 1 1 • • • . • S . . 

- - - 

- •- 

ELSE 

cc;  _ ....  __ 

IF  F 1 FlC_TYPF* »® ' THEN 

__  . . _stpingl*»  f*  IN  ( • ; 

ELSE 

IF  F If tC.TYFF*  »C*  JhfcN. 

7 1 
7 
7 
0 

STR  INGl*'  CH6R ( • ; 

...  ELSF 

STSIMRl**  F I XFC ( • ; 

PUT  STfil'iC.lSTt  iNOECITIFTELC.CCL.PBOTn.YAX.LFN)  ( 

F < S M ; 

S TP  INT.  1 *ST5  I\CL  1 1 STfl  INC  f 1*1*: 

9 

3 

0 

fc 

6 

6 

IF  F l tL«)_  TYPF*  • C * CF  I EL0.Lrf.TYOF  = • V*  THFN 

STB  1^ Gl *STP  INGl  I J * V &p  • ; 

STP fNGi*S ra  INGl  1 

ENO;  ..  . . . _ . . 

IF  0CL.PpQTO.TYPE  = MN* 

7 1 

IF  F UST.INJFRIM  THEN 

CO; 

lLtN£*#  f*rfR  !*•*.•  I 


CALL  nci  ( l , ft  fvF  ) ; 

F IPS?.  If:  TS®  Iy-  ‘O'0  *. 

t\n; 

fno; 

CALL  WkUCL  I 0CL_»On?*r.LE  VFL  ,1  IN?  J |$T3  INCH 


pa i irn  : 


IGPL1S0L:  P*CC : _ _ 

tlNCLUOE  UCU!1*  lOniCTI  ; 

CCL  r'A**  (l \r,  r f*n  Ftxcn  gifrCTL; 

'/-  -4^  |U  v'FC'rVip'  PARALLEL  TC  cicr,  WITH  a t'y Pc  f^oh 'i  TO  7 if  it 
ib  u*\t  f’F  thc  special  names,  c r thfp  w i se  */ 

CCL  s TO  r NG  C 7 I CM.'»(20>  VAP; 

CCL  ChEC k C / I CHAO(t^)  7AQ ; 

CCL  FLA*  I 7i  L’lTd  ) INITI  *C»P>  J 

CCLCCL.exI ST  ^IT(L)  IMITI'0'0); 

cc  l ~ p'j  i r f r _f. c • i r & a r p p~  ti\  r ( i ) *i  ni  t< • c*e1 ; 

/*  check  a^ay  contains  the  names  that  sfculc  pccup  as  the  initial 

SLoSTJlNC  L F Tu£  6n  TK  I c s IN  r'[rT  */ 

/•  F V 6 R Y cf  T°Y  in  nICT  MAS  ASSTClATrC  W»TF  IT  A VALUE  WF  T CH  TELLS  US 

[F  A * A T C H *A  S rr^j-p  w|T>  A GlvfcN  CFFC*  VALUE  */ 

/*  FLAG!  I I rcLl  S_j;S  T^Aj  TH^  |_NT4lf^  IN  GICT  THAT  m&TCF  CFECKIIJ_*/ 
/•  r Lmu  INDICATES  that  THc>*  E IS  AT'IeaST  CNE‘  I FCR  WHICH  FLAG(I) 

IS  TSUF  «/  ...  ...  . . _ 

ALL  LC A re  AUK; 

y a n K * c ; _ 

CMF C<  ( l » * * ChO  rc  c . • 

Cr  rC  ( 2 I * • i X t S 7.  •; 

cflc>  m*  • i-  e:;  . • ; 

CFtCM  A ) * * SIJPSF  T . • ; __ 

check < ;>=  * >ir  i:ire?.nio.'r; 

CHcCK(6)*,PriNTcP  .New.^J _ 

CFrCK(  M s ' 9C I NT c P . ’ ; 

STk  I*.G(<»  I .STc  f»:r,  ( l J *»JUT(  I ) f M T ( • •€•  #PI  , *J 

STw  ,st?  i“G(  ?'»*•  Ffx'ipn  ?,  »n,»; 

S T F 1 1 .G  ( S ) , S T P l N C ( 6 ) , STRING  (7  )_*•  CFA«M2CI  VA©,*;  __ 

DC  1*1  TC  Die T I Nn; 

/*  Ft’rf  EACH  ENTS  Y IF  CICT  A *4  a T C M KITH  A C F FC  K VALLF  IS  LOOKFC  FCR  •/ 
J*l ; 

Ju  WHILE  (J<C  l SUFSTmIPICM  n ,1  fLENCTHTMECKl  J)  ))-«CHFCMj)  ) I 

enu:  

IF  j < 8 the;*  on: 

/•  A MATCH  WAS  FCUNO  */ 

map  *.  ( n - j ; 

fl  aC I J ) * • 1 • 9 ; 

OCl.r  < 1ST 

FNO;  

ENC; 

IF  CCL.FxtjT  THEN  cn;  _ _ 

CALL  WMOCLIC.'OCL* ) J 


J 


IF  J <5  THEN  _ 

CC; 

LINE3  SUo  S TJ»  (CHFCM  J ) , i .LENGTH  I CHECK  ( jll-1)  | | • , • j 
C**L  L WRCCL ( l.L INE) S 

_ ENC; 

ELSE  IF  - PrlMTFR^GFNEPaTfn  T> E\  CC J 


pciNrEM.GEve^Arec3 
LINE*'  POINTER  , 1 ; 

call  wpocu  i » l i n e ) 


' 1 • p : 


ENC;  

! f j* 5 then  oh: 
nne*'Linf  * ; 
call  it*  jll<2»l  inf): 


enp  ; 


1 F ”j  = 6 THEN  TO; 


L I N c 3 * M k w , • ; _ 

CALL  MHOCUPfUNB); 

END;  

IF  J35  I J3*  THEN  KO; 

ELSE  *3?  I _ 

"/•  K *ePRESFNrS  THF  LEVEL  IN  THE  STRLCTURE  CF  "THE  NA^ETAXEN  FRCM 

oict  •/  _ _ _ _ 

oc  1*1  rr  oictt‘’C; 

LINE*  SUiJSTf  C TICTI  n .LENGTH  (CHECK  ( J I ) «-  L ) I | 5 TP  INC  ( J I S 
IF  HAKk([*  = J TmFN  CALL  WP  CC  L I * * L I k F ) ; 

end; 

"enc; 

ENC; 


r 


t 


•PROCESS('NST.N*GPOnrcc.^ACRO.SM»<2#72,llM: 

GPROCCC:  P»xOC(P  TR_rr.FLrWM6  I ; 

/•  THIS  PROCEDURE  GENERATES  2 SETS  CP  CCDE  FCR  ASSERTIONS: 

II  A CALL  TO  THE  ASSERTION  IN  *Ptl  $X± 

AN  L 

2>  THE  PMUCS0H9F  ITSFLF_INVnLVlNC  THE  TFXT  IN  •PLIPRGC*.  •/  . 

TOC L HAX.ltN.CNM  FIXFO? 

*MAX_L6N_QNH*32  J _ . .. . ... 

OCL  PTR_TO.FinwT A"  P T R ; 

f CcL 1 -VA  x_Fn!namE»  mAX  _L  _ N AH  E I FfxFC: 

SKAX.FN.NAmE*  T : 

Tf'AX.I.^NAPSa  10; 

/•  THc  RcCO^O  which  IS.  PC  IN  TEO  TC  er  TwF  ARGUMENT  PASS60.  */ 

PCL 1 _£LCw  T A °_A  S $U  8 A S F 0 (FLCW.PTP),  _ . 

? NO^f*  FIX60  ft  IN, 

2 N'Ofr  _ TVPF  CH/.R  | A t , /•  ASSN_?y 

? ASSFR T ICN.MAw?  C R AB  ( » A X _ L_ N A ME ) , 

? COMO.FCN  CNA->  (HA>_FN.NAHE  ) , .....  

2 REPLACE. LAeCl  CHAP(5), 

2 ALPEArY.CALLEC  P I T I l | f . ... 

? LPN.TFXT  F I XeC  PIN, 

Z-JE  X a R J N_P.Ef,F  P_IL  IV-tE  AT  ))l 

CCL  SHORT  .ri  iMF  r map  { *AX_l_NA*E  ) VAR; 

CCL  PL  PC  CrtARm  IN  I T ( * PLIPPCC'  ) ; 

CCL  CC.Nu  tNTOY(CHA9  I * »)  RETOPNSIS  ITCH  ) ; 

CCL  CHOT-IL*  cNTPYCCHARI  «|  | perrjPA  S <CHA9(RAx.LEN.C\M)VAP  I ; 

/•  FFTCh  IH6  RccroH.  •/ 

FLl  k _P T_R  * P rc_rr_Fj  rwr  A3  ; 

/•  TC  wh\tK4T=  THE  pa'll  ALL  wE  NFED  IS  THE  NAME.  •/ 

SHOP  r_*jA*F*CH£>T?  I 31  ASSERT  ir  N.  N A * f ) ; 

-IF  -.AL*-’ FAC  Y. CALL  cO  THEN 

CCALL  WRPLIl'FiLL  • I I ShO»t_mav? I I • ; • f « PL  i px  I J ; 

0/*  PROCEDURE  H*.S  NHT  BEEN  CALLCC:  Ch^Ck  IF  INvn.VFCTHE  •oEPLACE* 

F L \ - T 1 0.*:  t A^n  if  SC.  CFMEPATg  thF  apirCpRIATE  CCCE:  • /.... 

IF  CCNJ.FC'N-**  • • THEN 

CC;  _ _ 

IF  CCNO.FC.N*  ' RTPL  AC  f * THEN 

_ oc; . . 


CALL  Vi°  PL  11  • IF  ^ASncpi  THpNi  , «P|.  1FX»  ) ; 

CALL  W R P L 1 I • IF  -CHOICE  .F^PTy  THCN  CO  J ' , ' °L  IE  X • ) ; 

CALL  ApPLl('WASPEPL*,,C,,i;»,*PLlFXM: 

CALL  W»-?Ll(*Gn  TO  ' I IF  CPL  ACE.LA3  6L  | I ' ; • , ' PL  IEX*  » ; 

call  wkpli  ( ,SNC: « * » PHEX«  ) : 2. 

ELSE  

IF  CCfiOICCNC.FCNI  THEN 

oa; 

/•ASSERTION  IS  USING  A CCNO I T TON  ALLY  CCPPLETSO  fcCN«/ 

CALL  WFPLKMF  ' I ICHPTPtR  ICTNC.FCN)  I I 
'.COH  Plc'TFO  f Hc  N CO  « * » ' PL  l ?X  ' ) J 

CALL  wFPLl  lCHr»T?  LP  I C CNfW^N  HI'.CC'-'PL£TEra*'C,,P:'.»PLlcX»l; 

CALL  wrv  pl  l (CHPTOLCI  ASSFPT  ! CM.  N AH  6 ) | I • .CO PLE  T EC*  • • l • • P 5 • • • PL  IEX  • I : 

call  *-<pl  i ( * LNO : * , * p L l Ex  * ) ; 

END  • ' 

__  ENOj  

0/*  TO  GENE*  ATV'TmP*  PP  OC  ECU°E  W?  N*FC  THF  TFXT  - IT  IS  ALP  E AOY  CLEANED 
UP.  •/ 

cau  *f  pi  i ( shop  t.maf  f 1 1 • : prcceocpf  : ' »plpc  i ; 

CALL  WPPL l ( Tf XT , PL  PC  ) ; 

call  nxpuetw  • m shc*t_na.»ei  i • s s pipci  s 
cnu  gp-occc  : 


399 


400 


•P©CCESS(  •NST,MACP(?,N»tnFUOAS.SM«  I2f72,i>  •);  — 

icfilus:  panc(orcr/» » ; 

_ /^PP'  CcOUKE^  IP.  GfKPATF_FLCWCHAPI_®ECC,,n$  FCP  Implicit  a $SCC  I A T ICNS 

CF  FIELDS  0«  I N T.cp  [p  v'RrarHCS.  r HE  PAPAMfTfP  PASSED  IS 
THE  DICTIONARY  FNTPy  NIJM0FR  OF  T H E FIELD  C«  l 'EM*  VA»IaBIE  FCP  WHICH 
WE  ARE  GENERATING  A MnwCHAM  ENTOY.  EVEN  (F  T>  f F ( E.LO  OCE  S NOT 
RtOUIPE  IMPLICIT  ASSIGNMENT  CODE  TP  PE  MKcpaTEC  CI.E.  IT  HAS  A VALUE 
dY  VIRTUC  CF  AN  ASSERTION  CP  IT  IS  IN  A SCUPCf  ®6CC»OI • THFn  A 

FLlWCHAPT  .PcCQe.n  IS  _ST  ILL_/,EN_ECATFC_  ArvVWA  Y FCP  PEFCPT  PURPOSES. 

THUS  t A F LCWCMAQ  T ENTPY  WILL  RFSLLT  W>ENFvFR  THIS  ROUTINE  IS  INVCKEC. 

THE  TYPE  l N S£R  T F n INTO  T H E NOCE  T Y°E  $HCWS  WHAT  IS  T C OE  DONE.  ANO 
IT  IS  OCTERMlNcn  AS  FTLLCWS: 

0 01CTYP6 4CJNAT.IYPE *>  NCOE.TYPE 

0 1 FLO  1 l • FLCS* 

!_E.LO_* 3 OP  7 • F L0°! 

•FLO  ' * •FLOP  • 

• JNTR* 1 OR . 7_- MNTP'  

• INTR*  <*  MNTP* 

0 T HE  • INDICATES  that  code  WILL  PE  CENEPATfO  eY  G l *CL ° FCP  these.  •/ 

-/*  THIS  PROC  EOIIR  F ALSO  CALLS  • C MK  AT  T P • IN  CPCEP  TC  CHECK  THF  ATTRIBUTES 

_.)H_  TM^»u*CS..S%lO  TafCf  I_vaPJ[  Apt  £S  F C3  CC*pAT  Ih  I L I TY  » IN  CASES 

WHEkc  C JOE  WILL  oc  CFNERATEC  FPt  IMPLICIT  ASSIGNMENT  •/ 

-CCL  ChKATTk  EN  T°  Y I r I a fo  *|N#  fixed  3 I N ) r J rjxFC  BINS  - - ..  ..  . 

0/*  WE  CAN  DECLARE  *rST  EXTl»NALS  VI \ ThG  tlNCLUCE  •/ 
tINCLUOt  iNCLmCOICT  /•  CICTIO.NAPY  Cf  FULLY  QUALIFIED  NAMES • •/ 


ocl  apjmati*,*)  fixed  rtnapy  ctl  fxt:  /*  acjacency  *at  irx.  */ 

0/*  THIS  IS  the  rp  rug  FL  <“\*C  h AP  T OECCPC.  •/ 

DCL  l Ftuwr A*_E l ELD  P ASFC<pl jWTAe.F  I ELC  P TP  ) f 
2 Nl’DF  * C I XFO  aiNAPYr 
2 NCOF.TYPE  CH A3 (a  I , 

2 TGT_M£lc  CH*aV(LF'N_C  K T_ENTPY  ) , 

2 SPCr.rtFLU  Cm ad ( L FN.T  I C T. £S TP Y I , 

E LOW  T Art  r I L e OUTPUT  RECORD  SEQUENTIAL;  /*  rHE  FILE  TC  WHICH  ThF. 
PcCirtO  BELONGS.  •/ 

DECLARE  c.N»JlnG(  7ICHAP  u UNIT  I AL  C *s»  •f,p,#M»*#  •,»  •#*p,l; 

CCL  CODE  FIXED  c l»J_ ; 

CCL  ~ TTPr"‘CHAo  m ; OICT*  FIXED  PIN; 

0/*  r^e  type  IS  SET  TO  The  FUST  3 CHAO  aCTEP  S OF  THF  TYPE  AS  INOICATEO 
IN  • C IC  TYf*  r • » WHICH  SHOULD  PE  EITHER  »FLC#  C*  • I NT  • */ 

TYPE*  SU&S  TR (DICTY°F(DIGT1) ,1.3) ; _ _ 

0/*  TILL  IN  AS  *M  t C H OF  TMC  PFCCPC  *S  V*  E CAN.  */ 

L JC  ATE  F L 1>TAP._MELC  e I LE  ( FLOWT AS  ) ; 

\o><  E * SH I C T a ; 

TCT.FPLO*  CICTIOIOT#  ) ; 

0/m  LHL  c^  Thc  A P PP  DPP  I AT  F COLUMN  OF  THE  MATRIX  FCP  A N0N-2FR0  CCDE', 
which  SIGNALS  The  TY °E  nc  SOURCE  THAT  THE  FIELD  HAS.  AS  FOLLOWS: 
i *>  F I ? l d 1$  j\  a Sr UP C F PECCPC; 

3 *>  F j c l ^ HA  5 EXPLICIT  SCUFfF  CP0*  An  ASSERTION;  

<.  * > F t ELO  HAS  an  IMPLICIT  SC'JpCE  (ASSIGNMENT  CODE  WJLL  «F 

NECESSARY);  ANY  OThfo  TYPE  I*  ACJVAT  IS  lwPO$Sl?LE  •/ 
/*  7*  > FIELD  HAS  AN  EXPLICIT  COf.  C I MCN  AL  SOURCE  •/ 

OCC  J*l  TQ  H3C MND (AOJMAT.l); 

COOc-*AnjWAT(  J.DjrrY  ) ; 
if  cnnc-.*n  thcn  nn; 

"/•FILL  IN  Th?  3FSf  fuf  RfCC'C  A PFPC  °P I A f L Y . ♦/ 

/•  use  r He  cnne  rn  ofc. ide  what  to  co.  •/ 

NUDF_TVPF*  TYPr | f FNO  INGfCCCEl ; 

s J c e.f  tFin-r. icr  ( j) : 

/*  Cijc  <»  IS  TM^  ONLY  r A PF  WHF3E  PL/l  COCE  w r L L ?E  GENFPATFO.  •/ 

\f__ cnofe*^  then  co; 

“ ' CALL  CHKA  MR  (OICTO  • j)  ; 

e c TU« N ; 
cnd; 

IF  (CCjOE*1)|  (C°0f  = 3)|  (C.COE  r 7 ) TH^N  RETURN; 

ELSE  CALL  SYSEP.P  f *MOnuLF  : ICLFCAS  ; DAO  MAT  CODE  • I ; 

ENC; 

END; 

/•  KC  COOE  at  ALL  SYEEPP.  */ 

CALL  SYSE^'M  • MODULE  : IOFLOAS;  nc  ccje  fnccuntep.ecm  ; 

ENC  ICFLCAS; 


•PM  CESS! • NSI .MACRO. N» 
ICaSSn:  PR(;CUSSN*I  ; 

/•  this  procedure  gfn 

CCL  A S SN < MXFD  PIN; 
lUCtuGF  INCH  •MTU  l CT 
XINCLUPfc  iNri I B 4 r S€P I 1 
* INCLUDE  *lNCLIt>«?VsST 

<t:iCLU«»t  INCL  Irt  (OASSn: 
ZCCL  NAXR.CCAO.NGOES 
*Cl  L MAX.LEN.ON*  Ff 
TOLL  PAX.CtN.LA?FL  F 
< *Ax«_CCNu_N3QES»iC; 

I*  X . L t N_  L A 0 E L * 1%  j 
UR  a x_l6n_Q;*m  *32; 

OCL  CCN'OAS  (MAX  R.CUNC. 
DCL  «CC'.VJ#S  F l X CU  S IN 
/•  TAP.CE  OF  rjA-ES  r<= 
/«  OfcTECTEO  A»0_FNTE 
ICKEPl*  A VC  Che1 
CCL  CC\U  c-NT-iY  ( CHAO  t • 
CCL  ChPfPL^  c*l T° 

ccl  crcr»  fntryici 

OCL  CUiSQN*  ENT  3 Y 
(Cha®  (MAX.LPN.ONM 
ocl’ «e;'l_t atgft  cm** 

OCL  ( FI XtC.ASSF* T IVI 
CCL  STaNT  exT  o TP.  * 

CCL  ASSN.PT3 I T » PTR; 


*I0aSSN,SM«I2,72,1),6XTRSF«)  ; 


ERATES  A FLOWCHART  ENTRY  FCP  AN  ASSERTION.  •/ 

I ; ’ 

» )j 

XT) ; 

;i) ; 

F I X CO* 

XEO ; 

rxEC; 


„NOr»E  S I CnAR  ( *ax_l_NA*£  ) VAR  EXT; 

EXT.  /*  INCFX  TC~CCaCAS  TAeLE  •/ 

ASSERTIONS  That  USE  CONDITIONAL  FUNCTIONS  •/ 
RFH  t?v  THIS  RPtriNP  1 I CASSN  * » ANO  CHFCKEC  BY 
CPNC  •/  ’ 

n9eTUP»siBirn)); 

Y(CHAP(«I)  RETURNS ICHAP I VAX_LEN.CN*) VAR  I j 
HAR  (•  IVA-i  |FFTUPNS(F  rxfC  fl[N): 

(FIXED  3 I N » F l X E C P I N . PC l N T E R ) Pg TURNS 

) V A R J ; 

C«AX  J.EN.CN*  ) VAR; 

TI  All*  TASSERT*  ) t SPCH.NAMEI  CH  AR  ( M A X.L_N  AME  I ; 


CCL  CTR  F l xrO  «IN;  

CCL  CP^L.CMAO  •OmR.CFARI' "CHArT||  5 

CCL  IN.^UCTr  -3 1 T ( l » ; _ 

TOOL  'AAA_.FK.NAMf  CjxFri';' 

t VAX.FN_,S,1*F*7  J 

CCL  T. STRING  CHARTS  r.lFN I VAP  CK; 

OCL  J r ixgQ  91 M * ~ 

CCL  I.’.SRCF  T°  v I CH  A®  I • ) ) PETUPNS(aITtins" 

/•  This  IS  the  3SCO»f)  W6  ARE  TC  GENERATE.  •/ 

CCL  l FLORTA^.aSSN  OASEC  IFLOW.PTP.I, 

2 WOnF M FfXFO  PIN, 

NCnF.TYPC  CHARI/,)  f /p’ASSN  •/ 

. . 2 AS$P» TfOK.MA**  Ch  AP  I M ax. L. NAPE  I , 

7 CONO.FCN  CHAP  (NAX_F\_\APe1I  , 

_ 2 PEPLACC_LA"EL  Chap  ( 5 ) , ..  ..  _ 

2 ALPFAOY.CPLLcC  PITII), 

2 1 E‘J.T6X t FixEO  PIN, 

" 2 T Fx7  char  IN  »c?E°  <f£cwT  a 8~*  A S SN  • L EN_  TEX?")); 

OCCL  FILEST  ENTCY IChap (* ) ) UPTURNS (CHAR | 2 ) ) S 
OCL  rt^P.PLI.STP  CHAP</,7)  »/Afl; 

OCL  iCmP.SkC.p! LE  Chap  I 10 1 VAR; 

0/-  THIS  is  ANTTHfR  LINE  CF  OL l rexr  THAT  we  HAY  PERHAPS  cenerate 

IF_ ThEp  is  \ NEED  FOR  A TEST  QF  SUBSET  SELECTION  •/ 

ubci.  I FLU  *!  AC.It  EXT*  KASEC  I FLOvi.R  TR  f, 

2 NCCfcP  FIXED  PIN,  _ 

2 T YPC  CHAP!',),  /•  • TEXT*  •/ 


/*  wVuSE  KETRitVC  TO  GET  THE  TEXT  WE  MLS  T CLEAN  OP.  ♦ ✓ 

SRCM.NA*t»OICTl ASSN*  I ; _ _1 

CALL  «EMEv6(S»CH^A.MC|  (•CMIPrxfC_ASSFRT*,ASTX'  , S T A* T , ASSN.P TR , C TR  > ; * 

IF  CTR-*l  T hen  CALL  SvScRRf  MOASSN  WRONG  T£xT:  * II  S^CH^namE  ) ; . . 

/•  AS  PER  USUAL  Chase  TC  TMfc  TEXT  VIA  THE  POINTERS.  •/ 

S T 3N  A,of  .P  r»»  *.ASSN_PTP  c ij  ; a_ 

CP  * C A T A_P  T ; ^ 

/•  ALLOCATE  THE  TEMPORARY  STRING  WHFPE  Th?  MOC  t F J EC  TEXT  WILL  GO.  */  . 

ST.LEN*LcNTX; 

ALLOCATE  T.STR INC;  . _ . 

-/•  WC  WILL  REMOVE  EXTRANIOUS  RLANKS.  HE  "UST  DF  CAREFUL  AEOgT  STRING 

CONSTANTS  HOWEVER.  «/ 

P*L.CHArf» 1 • ; 

lN_LUOTE»*0'e;. 

T.SIEINO*m1 

OC  J*  i rc  lfntx;  

C'JH^CHARaStJ^STR  (STO  , J » 1 ) ; 

IE  P K E_C H A°  a * J T HEN  C?  ; 

IF  CUR.CHAR**  • THEN  OC! 

I F IN^OUCTE  THEN  T_STR  IE.C»  r.STPINGI  ICUP.CHAR; 

ELSE; 

ENOS  _ ......  . 

tLSE  T.STp  INC* T.STR fNG I f .CHAP  ; 

fNP; . 

tLSE  T.STo I NGsT.STR INGI  ICLP.ChAo  ; 

I.A.'JUOIF-W-HI  lN.CUCT6fCU»^CHAP«**  * *,*0110*9);  . 

pfS.CmAP  *CUp.Chco ; 

encT  ~ . ..... 

/•  SET  ThE  PEFFRING  VARIABLE  A\0  ALLOCATE  THE  RECCPO.  •/ 

N-LtNGTM|  T.STR INC)  ; 

LCCATt  TLLwf AP.-iSSN  f U E( clCui±8)  ; 

/•  f ILL  THE  PEC  JR  O.  •/  ..  . . 

TExT  » r.STP INC; 

FREE  T_S  T*  f NG; . 


FUiWTAo_ASSN.NCr»E«*AS$H* S 2 

r lp h r ab_ a s >n r ypf* • assn*; 

A S b fc  * T M;,_n  .**»£■  $0Cw_NAME  3 

-/•  RE  r n I L V E Th*-  A SSCc  T I ON  TARGET  STrtACf  EMPY  IASTGI 

PC*-’  FURTHER  ANALYSIS  •/ 

Call  F.fciVEvf  cs*c»\> avfT r*c*TT f i xic.a$scpt,  *astg~*  , st apt .assnIptr  ,ctp  i ; 

If  CTH-a  i IMFN  call  SYSERR( • ic assn:ast6  nct  founh • J ; 

STPR AGF .P  ra  * ASSN. p TP ( l | 3 
UP*  Lat  a.pT ; 

0/*  FIND  OUT  IF  ASSERTION  IS  AN  EXIST  CR  LEN  TyPF  ASSEPTlCN  CF  A NAME  IN 
IN  A SPURGE  FILE*.  THEN  ALREADY  f.AUFC  RY  euF  F f P UNPACKING  RCUTNS*/ 

Oa'lp  t ACY.CAlCEO*  r0*  R ; ~ “ 

oc  1*2  tg  »kfys-2; 

If  NAME ( f I* *EXf ST*  | NAVE  I I ) * • t 6N • THEN 

CO;  

ALRtAOY.CALLEnMNSPCF  (NA*E  I I ♦ D ) ! 

ENG; 


|o  o 


-/•  PINO  CUT  WHCTWFR  TH?  ASSERTION  USES  A SYSTEM  CClN'O  I T f GNAL  FUNCTION  OP 
r He  "°EPL  ACE"  FUNCTION:  •> 

CCNC.FCN-PCN;  /•  SE^S  Thf  FCN  \AVf  IN  THF  ASSN  FLCWTAB  ENTRY  */ 

-/*  FUST,  C*LL  FCNUSEO  TO  MARK  THE  FCN  AS  USEO  •/ 

Q CALL  FCMjbEClFCN)  : ; _ _ 

0/»"*FCN#  is'  EITHER  BLANK  INO  FUNCTION  USFC  BY  ThIS  ASSERTION-); 

ca  is  'replace*  (the  system  runic*’  pfing  usfc>;  or  it  is  the 

name  OF  A ^YSTFM-Porjv  I0E0  FUNCTION  WHICH  MAY  P F CQA  0 1 T I ONAL  */ 

-IF  FCN  ••REPLACE*  THEN  /•  ASSERTION  USES  THE  "REPLACE"  FUNCTION  ♦/ 

OC5 

/•  IF  FUNCTION  I $_J*R  cpL  ACEMEN  T^;  IF  SC , CETERMINE  ITS  REPLACEMENT 

VAkTahlF  a no  GFnFPATF  the  label  IT  will  ">®ANCM  Tn  |F  REPLACE 
fCG*  PLACE  V 

0 /•  SET  RE  PL  TARGET  VA°  I A n L E 4 ASSLMOYICM  MACE  HFPF  That  An  ASSERTION 

USING  Thc  REPLACE  FUNCTION  HAS  r\|_v  CNF  TARCFT  VARIABLE.  WHICH  IS  IN 
T He  'A  $TC*  STPRAGF  ENTRY,  STaPTINC  AT  PCS  2 ANC  HAVING  ^COMPONENTS  •/ 

QREPL  „ T Ah  G£  f *CON'SONM  f 2 , * CC "PPNFNTS  ( 1 I ,STCf  ACF.RTR  ) ; 

J*0|CT»|R6PL.TAOOFT) ; 

PUT  STR  INC  IREPLACe.l  APEL  ) EH  I T I • IL  • fJ)(A#P,<599*  ) ; 

OEno; 

-ELSE  /•  IF  THE  ASSCPTIPN  USES  A FUNCTION  C IT  IS  rCNC l T I CNAL L Y-CCMPLF TE 

i • 5 • it  is  in  the  •sysfcv  tapie,  then  fmfr  the  assertion's 

NA-F  IN  THE  »CCNCAS*  (CCNOITICNAL  ASSERT  ICNS)  TABLE_*/__  __  _ 

I>  FCN-»«  »~Tm£N 

IF  CCNOIFCNI  THfN  

oc: 

¥C0NDAS»RC0.\*0aShI  j 

IF  »CONC  AS>M  A X X-.CCNO_Nf,CES  THEN  CALL  SYSEPR 

< • l cassn:  Tnn_^AfY  ccnhasm: 

” ccnJas i ?c  eVo  a s>  * c h° t »\T (assert icn.name  f ; 

F-vo: 

-/•  also  CHEC*  if  yacgey  cc  ASSERTION  IS  A * sup  Sf  r . x » TYPE  NAMF, 

M£a;,|..G  That  ThF  ASSERTION  IS  C£SrF!PING  A SUBSET  CF  A FILE  X; 

IE  3C#  CHECK  IF  X ISA  SOURCE  CIL=  ANC  IF  SC.  Wf  .NEf:;  Tr 

C F N F R A T t CCOc  THAT_IF_rHf  SCU^CF  / f 0 C 0 C IS  NC  T IN  THE  SUBSET 

APFCirlcJ,  Then  ' CO  tc~=.fac  thc  NEXT  RECCRC  CF  THAT  file  •/ 

OLAST .POS.Su^SFT.fKEYS-? ; 

DO  re.  LAST. PCS. SUBSET; 

IF  NAME  IK )» • SUBSET • THEN 

CC; 

/*  CnFCK  IF  C C°  c E 5 PCNC INC  FILS  IS  A SCUKCE  FILE  •/ 

IF  F i L E S f C N AM  E ( K ♦’l  I I • *"SR  • THEN 

CC;  ... 

TEmp_S«C_f  IL  c»CHRTRL3(NAvf  ( *♦!  ) J ; 

/• _WF  APE  GENERATING  SPEC  I al-puPPCSE  CCCE  : 


"ir  -SUBSFr.x  tmfn  r.c  TC  «r D.xS:"  wh?f  = x is  a filfnamf  •/ 

TL^P.Rl  1_STF  * • IF  -.SUBSET  .*  I | TEwp^SPC.FILE  I I • THEN  GO  TO  SRC^» 

I I TCMP_SRC_C ILF  I | • S ; * ; 

N«LENr.TH(TfMP„PL  l.S  TP)  { 

L~*C  A T f_F  L 0WTA-2.TEX  T FILE  I JHOW_TAHJ  ; 

FL CW TAP .TEXT VNCCE <*0; 

FICWTA6_TfxT.  TYPE*  • TEXT  • ; __  

FLCwTAB.TcxT.PLl.STR*TEMP_PLl_STR ; 

6M0  5 ” _ ... 

f NO ; 

_ £NC_; 

-ENC  I CASSN; 


/ 
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• PSCCFSSI  • "iCRC’.FXTW  FF  1 ) ,N*1CICCC* » ! 

_1  C 1 «lLv_?.Lv.C  tPJ£T_(UJ  Li 

XINCLUUfc  lt\rL  I F ( TI2I  CT  ) ; 

XINCLUPC  If-CL  I p ( CANY  ) j 

xif.ci.uue  ifiCutuctiiSK): 

. xiNCcuoe..incLiD(x:seDiRi : 


J 


tlNCLUOf  t(\CLIa<PRECG3P)  ; 
tCC  L MAX_LtK_PR I VLA&  FIXECS 
*MA*_LrN_Oo  I VLAH*<»^MAX.L.NAMe;_ 

SDCL  MAX^kfN^ONM  FIXEO: 

z*  ax_len_cn«»3?: 

icCL  haxI'^l^s_6cT^  fixed: 

ThAA-FCUS^r.Er«e?CO;  

ccl  oict.'Nc  eiN  fix sni is!: 

OCL  l FTP.  *ASEP(  F T*_PT&  ) , /•  FLCfcTA8_PFC  */ 

2 NQDFf  e IX^C  n IN, 

2 NCNC^TVPg  /•  «9fCC»  • / 


c 


2 &ECNA«F  CHic iLFN.CfCT.FNTBY) , 

2 ICrtOCF  CHAP ( 2 ) , 

/•  »D  PC®  P F AC 

kR  for  WRITE 

Rk  FC®  PEwP  I T E '•/ 

2 FIlFNAMC  CHAR |-AX_L_NAvp | , 

2 d*G  CHARTi ) , 


J 


_ /*  S 

"1 

2 KEYED  FIXED  BJN, 

/• 


SECUFnT  I AL 
INCSXEC 


•/ 


NOT  KEYEC 
*E  YEP  •/ 


1 KEYNAME  CHAC ( MA X^L,NA VF ) , 

2 PACKED  ~ ~ 8 fv  FlXFC(l5ft 


/•  C 
t 


2 ®ECC®0_A=ITY  M*'  FIXCC(  15)  , 

Z_  «S'jh<Tct|CT!jE  CS £IX  = P(15K  

2 S0i»5TRiJC*t!J?  £(N  i»CpFr-{  FT ® # P S Cp"  S T P L C f 0°  E S J I • 

3 F.AMF  _ CHAO  ( LFNGTH.KEY^  AMf  ) f 

i TYPE  C***(l), 

/*  F 


NOT  PACKED 
PACKED 


• SMHSCp IPJ  S_ 
'sueTscr  I°T  l 
SUfeSCR  IPT? 
t XI  ST_P®i>C 
A®  I 7Y 
rjATA^TYPF 


FIELD 
G3OUP  •/ 


BIN  F TXFT (15  ) , 

«in  FixcruV), 

ft  IV  f ! X e C ( 15) • 

C*-AE  ( LFNCTH.KE  Y^NANE  ) , 
ft  J " FlXFCt 15) , 

Chap  ft), 

/*_C 

3 

K 

F 


3 F IFLn.LFN.TYPE 


_Cha«  m t 


/♦  F 
V 


« IN  F IXCCI  1 c ) , 

0 IN  rixFcim, 

CH  A* ( LFNCTh.KEY^AAMg ) ; 


CHaF  AC T E® 

’(NARY 
NUMCR  IC 

FIXED  CECIHAL  •/ 
FIXED 

VAo  I ABLE  •/  


3 -4  l*!~L  cNOTH 

3 MAX.LFNCrH 
3 LE?i_p*OC 

OCL  FTk_PT®  9CINTF0  eXT; 

-/•  THIS  IS  TmF  TEMPORARY  l DC  A T ICN  Cf  INFC)PMflT  f C N U»- TCF  WILL  FIND  ITS  */ 

/•  WAY  INT>  ThF  >JQPFP  PAST  QP  FTP, */_ 

“CCL 


l UPPFk , 

2 none* 

2 NCOC.TYPF ‘ 
2 * FCN AMf  _ 

2 IC'COE 

2 F (LFNAMg 


2 CNF, 

2 k EYFO 
2 PACaFO  *" 
2 KCYNAMF_ 


6 IN  F I X EC  ( l 5 ) , __ 

Chap  ( a ) , 

Chao  j LEN.DIC  f.FNTPY ) , 
CHAO { 7) , 

_C  H AP  ( * A *_  L-  N'AV  c )9 

Co/!0(lii 

ft  IN  F IXFCI I 5 I , 

BIN  F I X E C ( 1 5 ) , 

_ C-AO ( K4X_L.N AMF ) 9 


/ 
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2 RECCRO. \a  l ry  ___  PIN  FIXFCU5), _ 

2 *SUBST-uC  TljOFS  PIN  FIXFCU5I; 

Q/m  Tpv.p  is  USFO  T n HOLO_  7HE_  SU*  S 1 MIC  TUP  E EAT»lf$  hHCH  FC»*«  THE  LASJ__p/ 
/•  (LCmkkt  PAQT  PF  FTP-  •/ 

CCL  I TC^P  CTl  , 

2 NA^'r  CHAP  CLEKGTH^KEY.KAHe)  , 

2 TYPE  CHAR  (Ilf  _ 

2 isuttsrpiprs  * si*  fixeciis), 

2 SU»SC^IPTI  3[N  FlXSC(lS)t 

2 SUBSCRIPT?  BIN  FIX?CIl5lt 

2 _EJU  ST_P'U)C Chao  ( LEnCTH^XEV_KaM£Ij _ 

2 APITY  a IN  F IXEC( I5*v 

2 0AM_Tyr»e  ’ CHAO  { 1 ) f 

2 F IELO_Lcn_Type  “ Chari  i)v 

2 MlU.L6Nr.TM  _ . ® IM,  F IXPf!(  I5lt  

2 max. LENGTH  BIN  F I XTC ( 15  I » 

2_L6U.®R<1C CHAR^I  LEN.CTH_i<?Y.AAHE  )J 

~OCL  KECNAMc.oFTFEV!!  CHAR  f LENGTh.KEY.h  AH?)  ; 

CCL  START  5>UPirc0  «•  x T ; _ 

CCL  STOPaCS.pTo .LISTIM4X.FLCS.R6TRI  PTR; 

OCL  *.$  1 QR  aGc.T  \'T R l 6 S FlxFO  3 IN;  _ 

CCL  F IL6NA.<f  .Pr  TREVF  CHAR  ( L EnC  Th.kE  Y.Ka  MF*  ) ; 

CcL  flAFC-.F  ILENA^E  CHAOI_LE\l£TH.<FY.N_AyC)  VAOY  INC; 

OCL  iTC3  AGi  J'rV  l C c.NA,/p  CHAP  ( LEND  Th'_KF  yIn  AMF  ) ; 

CCL  STCKACc.TYPF  CmarIA);  . „ _ 

OCL  SCU3CE_=TLE  PfT(ll; 

CCL  7 Afi  GC  T.r  !L c uITtl);  _ _ • 

CCL  SLi-FlX  CHAT  It);  /•  S C3  T OP  U •/ 

CCL  .NU,Vd&W_J!C  »ICBsq«JM«;  /•  iJSFf!  F^B  SFNOINC  MJVEP  LC  _I  NFf] 

TO  S Y S c F ° • •/ 

CCL  CHAK.FLAG  CHdP(ll:  /*  IISFC  f(;°  0 6 TUP  n I AG  INFC  from 

f I EL^.Cp.jPCUP  • •/ 

CCL  I BIM  PI>n(l«|;. 

CCL  iMfcAoc1'  BIN  Fixrcusi; 


^Cl.^PEIlE  r.H>c  (l  e>irih  <cy  NAHEI  EXT; 

CCL  *7F"®$  TIN  FfXFJflS)? 

LCL  ChPI^L--  EnTR  YCCHAPI  •)  I P6TUPMSICHAM  LEN.C1CT.6NTRYI  VARYING)? 

CCL  WSL*R  «=>,Tr  Y(  Cma?  I -r)  ) ; 

CCCL  PICT*  £\ fc  viru.vM  •)  V Ar  Y ! \G  ) 3F  TLR>  S ( P IN  FfXECdSM; 

/•  udvinUS  CTCM^NA=Y  CF  FEQUES7EC  NAME,  C Ic  NONE  . */ 

Ouc  L A J L C k r A H_C  'ZVfl  A $ £ c r F f.Cfc  .7  A c N p_  PTR  ) t 

2 NCUt*  a in  r ixei:(  15) , 

2 UJOE.TYpc  Cha®!*),  /•  •CCNH*  •/ 

2 CON'jInAMF  CM  ?.R  ( * AX.LFN.CN v I ; /*  NAME  CF  CCNCirrON  •/ 

OOCL  S«/o  SET.  '4«r  CH&P  »)  VARY  JVC; 

0/*  LABEL  C-.^PCS^C  Cc  1 tPC.»  iTf  IL6NAVC  prp  ORtvfKG  FILE;  */ 

_/-  .LScO_e y »f.y  FLT»„yy.iCgnca_  tq  C?avCH  pack  tc_P£AC  Th=  KEXT..PECCaQ._?/. 

OCL  ■u^IvlA.a  PHAP  i^ax.LlN.O- IVLAP  ) v \P  y i n G FXTFRUAL; 

0 CALL  lOirC^.CALLCC;  7*  LAPEL  S Y S p p I 7 THA  T V6  WERE  CALLED.  •/ 
iJP?6  - . NCf®  * * C I C r _a.c  ; 

UPPcP.v.’nc^rYPra^SCC* ; ..  . . _ 

UPPbF.FECNAHE«ClCT( CICT.NC  )T 

-/•.Jj^op.any.  P«  - r_|  / _LVCL3.#J!_C®  J^Eh.  * ) _ FR CM */ 

/*  UHPtK  • K l C N 1 v f m CF  7 P£C^1"r.Pc7Rf  V?,  J\  LSOUM  IF  j£H  p?ZCRC  */ 

/•  NABC  USE P T1  ccr  7 h f FiLFNAMg,  etc.  _ . */ 

0 I H (l  = IMMb  XC  ijPP  f*  .PEC^A^H#  • Cl  C • • ) ) I 

(1  a I.I'TEXCMPPF?  ,»cCNA*F  » • \6w  • • ) ) 

7hF\  KFCNA--  F^cjTTRrv/p  ,su«STPlUPPFF.F€CAAH?f  5,  10); 


/• 

t « 

0 


tL5E..KcCNA  •: eV l£UP.°.6? 

WHAT  [$  rhc  citfNAvc? 

F iLEUAMr  TREVF  WILL  BE  USED  RETogvE. 
dAKr.F  1lfn\v'"  RlLL  CCN7  MN  NO 
.CALL  RE  rPcVCTFFCNA'Tr.TETAt.ve 


7C  A ILINC  PLANKS. 

It  'C1FILE • It 


*/ 

•/ 

*/ 


Algoritha  ID IOC D 


l* 


5 


X T * .* 


/ 
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r 


• i • ii 

PFCNAME.OETREVE  ||  •C1REPT 


START, 

STC o AGE . p TR  _l 1ST, 


l.STOC  AGT.6NTK I ESI ; 

0 IF  *.  STORAGE,  entries  -.a  l 

Then  CALL  SYSERPt  m'qioco:  ‘no  file  fcr  pecorc  •••  II 

* fecnamf.qetreve  1 1 

*"r  "••••); 

0 STURAG£,PTRsSTCOAGc.FTR.L I S T ( 1 ) ; 

~vT£«\T‘nu  a LOCKING  at ‘The  stop  age  entry  fcr  a *pile*  STATEMENT. 

0 cILENAM*.RETR  FvrsKrY.ENTRYdl  .NAPE  ; 

EARc.F iLENAMFsr HO  roLe ( F I LENAKF.PFToevE  I ; 
UPPEF.,K?YNA.HE-KCY-FNTPY(A)  .KAMC  ; 

0/*  KEYNAME  rLAMK  »»>  UNKEYFC 

0 IF  UPPgo  . Kc  yNAMp»  • • TURN  IJOPE1*  . *EYEC*C  : 

ELSF  UPPFR  .KFYEC"*l  ; 

STQrtAGr.rEV ICF.NAPE  «K E Y.F \ T» y ( 3 ) .NAMf : 

✓ * IF  not  spec  I p I EQ  AY  The  user*  then  STORAGE. DEV  ICE. NAPE  WILL  86 
/*  0 L ANK  • 

/*  ASSUME  S CAPOS  (SCQLI  if  input’*’ 

/ • PRINTER  < S SCL  I IF  OUTPUT 

-/•  F I NO  UPPER *C°G* 

IF  STOP AGF.CFVI C?.NA*F= • • /*  UNSPECIFIEC  •/ 

then  upper. cpg* • s • ; 

ELSE  oc: 

/•  FIRST*  JOT  rue  S rneAr,p_fYf>E:  CAST.  PRAT,  CIS*#  ETC. 

0 CALL  RCTREVF  (Stnc  AGE^rcy  ICE.N'*E  \\  1 C -» tF  I L E r.-tRPor  • 


V 

*/ 

*/ 

_*/ 

•/ 


•/ 


ST  AO  T, 

STPO  age .p TP.LlS T , 

STOP  AGE. FNTR I ESI ; 

IF  *.STG- A0C_ENTR Ir S -»  l 

Th  cN  CALL  SYSFRo  ( > IC  fpCr: NC  ^frq/icF  P?PMj*^FnR_ 

•STCP  AGF.CEv  ice"  \>-vc  • * • II* 

ST.GOAGF.CEVICC.NAPE  M_ 

MM); 

STCKAGc.PTr?  *STP0A,CC_CT*3_^  1ST  ( 1 ) ; 

UPaSTC7 'Gr.6NTRY.CATA.PT; 

STC®  AGF„TYPc*\4Y_STmT  .TYO^  ; 


J ). 


-/*  anything  ctheb  than  cisk  is  secuent  i n . 

/*  Ir  IT'S  OTSK*  CHECK  THE  0 I $K  C^GAN l ZAT ICN. 

0 IF  sTOk  a*GF.TY  PC3  • G J SK  ' THON  UPPEP.CcC*CrSK#CRGANIZATION; 

_ EL  SF  t'RPFR  .CPC*  • S * ; 

Emo  ; 

*/•  _ I S THIS  FILE  USSO  &c  •SGUc,CEo  gc  • r,\PCET*  c°  9rTH? 

/•"bUOLg  AN  VAPfAHtR'S  "’SOURCE  J^ILe”'  ’ AM:  "T  AQCE  T.F  ILF"  HAVE  MEANINGS: 

/* _ S^UKCE.FILF  IFF  FILE  IS  * SCL'RCE 

/•  T4CGFT.FILE  ’ IFF  FILE  IS  A TAHCET 

0/*  IS  IT  A SOURCE? 

CALL  Rfc  TR  E'/E  ( e I L ENAmF  Jr£  trGVE  * 

*S RCF»,  


*/ 

*/ 


•/ 

'*/ 

*/ 

*r 

• / 


STAP  T . 

STORAGE. PTO.L 1ST , 

*. Storage. Fntp i cs I : 

0 IF  •.jTORAGE.FNTk  ILS_^*  0 THEN  SOURCE. F I LE*  ' l • ?.  5 

EL Sp  SCUPCeIf !L5*»C»8j 
QJ • I S |T  A T _A0 GOT? 

Call  petpeveifil  f.nahe.retreve  * 

_ »tapf»  , _ 

ST  Ao  T , 

storage. PTW. LIST, 


a_$rn<iAce~enTP  its) : 


0 

IF  #.srnRAGF_5NTR IES  ^*  0 THF  N TARGET.FlLE*'  1*0; 

CL5F  tarcet^f t L E * • c*«; 

0/* 

ERROR  IF  NEITHER  SCURC*  N(1P  TARGET. 
IF  < **SC'»/PCE_F  IL  c ) C I '•T  ARGET_  F I L 6 ) 

*/ 

THEN  CALL  SYSEOP ( • ! H 1CCC:  FILE  •'*  II 

FILENAME. RFTarvE  || 

-/* 

•••  IS  NEITHER  SOURCE  NCR  TARGET*); 
WHAT  is  THE  l CODE  ? 

*/ 

9 

0/* 

/• 

•OLD.'  **•>  'pH*; 

•NEW.*  ***>  ( SECL  **>  * WR  • ; 

*/ 

_V 

/* 

/* 

IN OCX EG  **>  1 RW  * ) ; 

NO  PREFIX  **>  (SPUPCE^FILE  **>  *RC*J 

*/ 

•/ 

• 

— 

/• 

0 

tafget^ftlE  **>  ' Wc  ' ) • 

IF  I * INOEXf  UPPER.  RECNAMF,  'CCD.  *.i 

Then  UPPER . io^oce* *PC • ; 

ELSE  ' _ 

*/ 



— 

0 

IF  l * f NOE  XI  UPPER. RECNA^E.'NEw. * ) 

THEN  IF  Uop CP  .C° G* ' S'  THEN  UP  P EP  . f 0 i*CCf  * * WP  • ; 

FLSP  UPPER  . I0MCCE**RW*  ; 

ELSE  /•  NC  PREFIX  */ 

IF  SOURCE  FILE  then  UPPFR  . I CMCCF*« rc« ; 

— 

-/• 

ELSE  UPPER . ICYpCE* *WR • ; 

COMPUTE  SUFFIX  »S*  PR  *T*  CJR  *L'  FCH  FILENAMF. 

IF  UPPER ,0»G** S' 

THEN  UPPER. (Quore* •PC  • THEA  SUFFIXs'S*; 

ELSE  SLFF  l X* ' T ' ; 

ELSE  \f  tiPoEfl.ORG**  I ' 

•/ 

a 

- 

Then  ic  soufcf.f  ile  g targe T_f  f l e 

thfn  siif^  i x a * u • ; 

CL  EE  IF  SnufiCr.FUe  THEN  SL'FF  IX**  s » ; 

ELSE  SUFFfX*»T»; 
cLic  /•  IIP  PCR.ORG  IS  N E f THF  R *S'  NO?  *1*. 

CALL  SYSF-JP  ( M Olf'.Cn:  ILLEGAL  0*0  ••*  II 

•/ 

— 

— • 

UPPER. C?.G  II 

FPH  R FC A am  £ IJ  

UPPER.PECNAME  | | 

-/  « 

UPPER.  F ILENAMC*b* rLFNAyc  ||  SUFFIX; 

OC  wE  N F c P CLOuTAP^CrNC  FGF  a $LQSFT  SPECIFICATION? 

*/ 

/ * 
/" 
/• 
/* 

/« 

FUST  cr  ALL.  OCTFR-MNF  whET*-cp  CCINC  ic  FF  a wpirc  np  Pfv.PITF, 
a \i)  in  that  casf  whcthfr  jr  has  a corpespcn't* i nc  supsft  SPECIFICA- 
TION. IMIS  IS  jr\  S IN  CKUtO  TO  GENE  PATE  CCf.C  IT  ICNAl  CODE  TO  TEST 
FOR  RUcT^Fo  r*z  PFCr«C  IS  IN  The  SUBSET  SPECIFIED.  LOOK  IN  THE 
DICTIONARY  TO  SF  E WHCTHEfl  Flip  *-  a s a CCRRF  SFfAC  rNG  SUE  S FT  SPFC. 

IF  TArC.'T  c IL  E _ _ . ... 

•/ 

*/ 

•/ 

•/ 

*/ 

10 

— ■ 

I hem  cu; 

SUPSFT.NA^r,  •SUBSET.-*  II  C E_c  ILEAAME  ; 

J*OfCT« < SURSET.NAMg ) ; 

[F  J>0  ...  .... 

_ - | 

»h€n  00; 

ICC i rf  rturje  CC\C  cILf(eLCWTAB): 

— 

— 

F L U W T A R C N 0 • N OG  £ • * C I 

clQwTAR^CCNC.NOCE^IyPEs'CCNC*  ; . ..  . _ ... 

PLCWTAP^CrNC.CO^O.N  Aoc*S(jpsfT_mamc  ; 

END; 

- — - 

- - ?] 

zJL*. 

EMC; 

SAVE  L A K 5 L ro  DRIVING  e f L E • IF  .1  ff  f A TE  . AS  *U»IVLAB*; 

*/  . 

/* 

WILL  pc  USC">  HY  * CEN  F l T ' TC  HP  AN  CH  P*CK  TC  PEAC  NEXT  PECOPO. 

IF  UPPlR  .IOMODE*'PD'  ..  . .. 

-/ 

Then  if  uppep .cpg«* s* 

THEN  I*  UPPfP.K£YED*C.  ......  ........  ....  

408 


THEN  0*  l VL  • $RC_»  ||  CHPTRLKUPPEP  .F  IL8NAMF)  ; 

i/*  uces  this  recoro  rfouue  pack  inc/lnpack ing?  •/ 

0/"  IF  Nc  l T HFC  * T a Pf  * M • R *01SK*  NCR  *T£p»'*  THEN  "NC".  */ 

IF  ( STORAGE_TYPF  'DISK*  I 

£ I STOPAr.c.^YPF  *TAP£»)  11 


c i * torage_typ e 'tehm'j 
then  uPprP . ° ackec*(K 

ELSE  /*  CHFCK  PECFM  in  OaT^FNTRY. 

/•  hrue:  WE'f-E  P FLY  I NO  CM  THE  SIMLAPITY  OF  THE  FUST 

/*  rTE^S  IV  the  OAT  A_cNT P f E S CF  *Cr?K»  ANC  *TAP€ • ANC 

/*  *rcpM*.  watch  out  if  these  ape  chancec 


niSK.OECFH  > l / * .NOT  F C«  Fe  */ 

TmEN  UpPEP • P AC  Kc  C3 i ; 

ELSE  UPPEP .PAC KEC=C ; 

IF  Nil  PACK  TVG/JJNPACK  ING  N E C C E C , THEN  WRITE  FTR  CUT  TO  THE  FILE 
FLUWTAd. 

I F UP  PER .PACKEC^O 

then  ca; 

f*  FILL  The  LAST  entries  CF  UPPER.  */ 

UP°Ep.RFC"cC_ao  [TYsO; 

UPPER  . •SU^STPUCTIJPFS*  l : /*  GRATUITOUS  ♦/ 

LCCATE  FT?  ANC  CCFaTF  A GRATUITOUS  SueSTPUCTU'PE  ENTRY. 

N_-l5 

LOCATE  ftp  F I L 6 ( CLCW  TAPI  S.f  T { F T P_PTR  ) ; 

**UVfc  CATA  FkOH  UPPER  TC  FTR. 

CALL  *CVE_UPPER_TQ_FTP ; 

GOTO  FtMSHFO;  7*  FOR  RETURN  */ 

ENO: 

1_F  WE  l-EACH  HfPE, THC\  T^jfrnrjccns  TC  °>z  P AC  K £ C / UN1  ° A C X c 0 • 

(TkEAfc  UF'fLE  US'E  I‘1  RFTFFVlNG  PIFLCS  ANP  GP-CUPS. 

*PF1L£=MP*  ||  »AO£_F  rcfNA^E ; 

St  T ST.jr  AGE_EKTRY  a ^0  0\TA_F.NTOY  TC  PCINT  TC  THE  RECCPC  UNOER 
CUNSIOFJ AT  ION . 

CALL  PETREVC (RFCNAMC_pETppve  ||  .£«of;cc  ' ||  • | • || 

JECnAhF_PEtQFV£  I I •CSPOTN  \ __ 


v Algorithm 

■'  IDFACK 


ST  AP  T , 

src°AGF”prp_L f sr * 

*_STQF  AGE.FNTP  TEST; 

IF  J»_STORAGE_FMTP  I fs  l 

THEN  CALL  SVSIgPlMCIO.CC: • I I R F CN  AM  E.R  E TP  F V E || 

•••  DCF's'  not  CCCL’W  IN  EXACTLY  cne  "»~Tl 
•PECC/RPTN  ST*T  * I ; 

STUP.AGE.PTC  =STOPAGF_PT°_L  1ST  ( 1 ) ; 

GP=STCF  AGc_Fvfv  Y.0.1  TA^PT  ; 

PECorp_I°irY  can  *£  c l L L E 11  IN  IM*EC  I ATELY. 

U P P c \ . c cCnP  r»  AP  ( T vrscCGPP.avF^&coS; 

' C-ifcATL  TE^S  FOR  EACH*  «E'*«FRf  TR  ACI N C~  CU  TITHE'S  TP  LC  T UP  E~  CF  THE  ' 
P-ECOPO  IN  PPEFIX. 

IMTUlUF  *TfmpS  to  C."" 

</TFMPS  = 0; 

CO  I Mc.vSFfi  * l 7?  umPE®  .RFCC°o_a»  JTV; 

CALL  CPEATF_TE^C(RTQRAGE_E\tpv.NAvF ( i^fypcp  t [ ) , 

r»  crc=o  . AS’Jt  C UevPFF  ) / 

RFCGRF.F  u«t_SLF<  IHEMSEP), 

RECC.PP  .SFCCNC.SUri  I v E M 6 E F.  I I s 

E \D ; 

CN  RETURN  FPON  CF  c’ATg_  TEVP  ThF°F  will  eF  A STACK  CF  TFMPS,  ONE 

■'  FuP  Each  NA*F  WITHIN  the  ?£CrPC  STRuCTURP. 

LOCATE  FTP.  •»/ 

N=*TEMPS: 

UPPER  .«SU3S  TpuCTU®fs  = aT6m'pS  ; 

L CCA  T t F T °__F  I L E I F L O Vi  T A H ) SET  ( F T o _ P T P ) ; 


Si 


J 


\ 


i - I 


-/ • FILL  TCP  PAP  r OF  F IP  FKQ  H UPPFP  . •/ 

CALL  ^CVF_MfM>FR_Tr_P  TP  ; 

COPY  THc  TEM°S,  Tn  PEVEPSE^SFCUENCE » INTC  FTP  .SUBSTRUCTURE!  •» . 

CJ  !*JTEMOS  TO  l OY  -l; 

Cali  mi  f tr_slps tqlc tupe < u ; 


FREE  TC^P; 


6NO; 


FINISHED: 

PL  T to  I T(  • LEAVING.  IDIOCO*  M _SKJPf  ajj 

RETURN; 

JL  IC  lCCC„CALLFr* PoPCj 

-/•”VjK  riesuGG*!*.";  P*JP POSe £ - 

/*  THIS  PPnCEPLiPE  wRIT-ES  _A  LAPEL  TC  SYSPRINT  SAY  IMG  T PAT  ICICCC  __ 
/•  WAS  CALLED. 

PUT  ED  l T (•* ****••*****•*•*•' )_  

(Sk [P(2)  .a|  ; 

0 PUT  c 0 l T ( » t 1 'll  CCO  CALLEO  »«  ) 


•/ 

•/ 

•/ 


( SKI®, A) ; 

0 Per  £C[  T<  » ***•*••.*••♦« 
(SKIP, A); 

-RETURN ; 

END;  /«  ICICCD.C ALLEO  •/ 
IHCVF _uPRcR_TC_F T» : PR~C  : 


>»  ) 


-/*  INTERNAL  TO  mneo. 

0 /*  THIS  PPCC  FO'lp  F MOVFS  lNFCO"ATlrN  FRCV  li°PFR  (A  TgMPCRARY  DATA 
/•  STRUCTURF1  T1  rue  FTNALLY  ALLCCATFO  FTP, 

- FTR  .NODE *=*UP PE •*  .HOOE*  ; 

ftp  .;jorE_TY?>c»ljpoc3  .npce.typF; 

FT*.*  CCNAVC  *'JPPF?  ,pcCSAM_ij 

FTR  . ILfCOe«H‘»oeP  .’I’n-CCE  ; 

FTk.F  ILC*  \ves'JpP5c  .F  ILENA^F; 

F rR.tHG^MPOFP  #rioG  ; 

r TR  •<  i Y€V*U*oe.*  .KEYcC  ; 

FTr.  •Packco*mpp  = p.packfc; 

FTP,  -ieC  I TYsUPPF£.P^CCPf'-Ap  I TY  ; 


•/ 

*/ 

•/ 


FTP •RSueSTPUCTUFES*UPP£P .»SU(?STRlC TURFS; 

upeturn;  _ 

F\n;  /-  MCV.e J|3PcP_TC.FTP  */ 
lFlLL.FTF-SueST?UCT»*PF;  ORfC  ( I S T P UC  T)  *, 

-/*  t k r E r al  t>  mrcc. 

_ jJ  / V T 1 1 S _P  »(•£  c Hi ,e  e TF  A NSFERS  1NFTP  -a?  [_C  N JF  * C R_  A . J £-  o _ S T P UC  TUP  E_J  N T'J 

/•  Th;  FINALLY  ALL'CATFO  FTR. 

-CCL  ISI*LCT  j I N FIXFOC15); 

MR.JArLC  IST?UCT)^TERP.NA-E  S'  • 

F TJ  . TYPr  ( I STRUCT  | a’-cvp.TYPF  ; 

FT-.  •*#SLiSC,>  I PTS(  I STRUCT  » «T»*Mf  .#<LPSC»  I PTS? 

f T3  . s.c?  SC1LP.T  l f J S TJZJjC.U?  T Fw? . 5u « <CR  I FJ  1 ; 

FTP  • SU^SCa  I pt,I  I ST-.  lCt  ) - T£"P  . S U 2 S C R I P T 2 * 

F ro  ,F  XI  ST.ppoc  ( I STt  ijCT  I *TF-P.  F*  t ST.PPCC;  _ . 

FT- . a* l TV(  ! S T«'Jf  T ) = TE*°.A£MTY; 

f r j . i,  at  a_tvo  = ( j 5 tomc  T ) * t r *p  ,r  a r 6 _ r vc E ; . 

FTR  , F tcl.n_L?':_TYPc  ( I ST^UCTI  aTcRP^F  IFir.LEN.TYPE; 

c T r Jn^l^.-iGTmi  IST°UCT  > =TF*°  ^.LENGTH  ; 

FT*  #MAx7*.FNGrH<  rS7PLCr^’,cvp.MA<<“LE.NCTF; 

FTP  ,LtN_PRUC  ( I STRUCT  )«TFuo  .LfN^PpCC  *i  

-PF  TURN; 

EfD;  /-  F ILL F T^.SUPSTRLC  TU9^  •/  

ICPfc  ATE. TEMP  ; THT»'0NA“F  , «SUHS.SuBl  .sue?)  FECLPSIVE; 

./n  jNTfRf.Au.  T-5JLriQCJC.t. 

0/*  Tu|.,GNA«E  "AY  cr  ‘►-r  \AMP  “r  A 0 R c U F CP  FIELC. 

/•  fsucS.  sue  it  .*Nr  sup  2 ofsc-fnc  ►‘Qw  ;may  cf  tfis  thing  appeal  in 

/•  The  RtCbPO  s TR  UC  TUP  c ; THFY'SC  G C T T £ N F °CV  THE  NAMb  I T I A T EL  Y 
/•  AuCVE./uIS  CNF. __  . ..  


•/ 

•/_ 


•/ 

•/ 

*/ 

_•/ 


it 


-CCL  T h I NGN AM F CHAR ( LENGTF^KFY.NAH E ) 
DCL  ( OSUbS, SUBl ,SU32)  BIN  F I XFQ ( l 5 I 

-/*  Note  THAT  

/*  STORAGe.PTR 

/ 


• S TOWAGE  ..PHI.-L  I 

/•  *.sTr^AGe_FNTR  i es  •/ 

/*  MUST  BF  local  TO  C«CATF_TrvP  IF  IT  IS  TtTeg  RECURSIVE."  ' ’ •/ 

OCL  STGKAGE.PTr* pC  TNT ER  ; 

CCL  OP  PC  INTER*. 

CCL  STU RAG_c.PTR.LTJ T(  *\X _ el OS_P 6 T R ) P TP  ; 

ccl  sTc « agf'^c n t p i r s p in-  fix c cl  15); 

OCL  l STOPAGC_r.  M T5Y  BASFCISTURAGF.PTR)  , 

2 <#KcYS  F IXEO  BINARY, 

2 Qu  T A_o ' POlNTFo,  

2 *rY_ENr°Yl\  REFER  MKEYSfl  t 
3 NAME  CHAR  (L ENGTF_KF Y^KAKE  I . 

3*  M-XT_PTP  POINTER* 

• INC  LUO.fc  I.\CL I 3 ( OF  I FLO ) • 

Algorithm  CREATE -TEMP 

/•  INCLUCES  CCL  OF  FTELO  TEMPLATE  

• INCLUDE  INCI I3(CRECGFP)  ; 

/ *_INCLUC  ki  OCI  CF  RECGRP «/ 

:/*  13  TVi  NONAME  a c I FID  CF  a GROUP?  •/ 

CALL  FlcLO_'~P_ORf'i_iP(  THINCAAMC  ) ; 

IF  C F AF  _F  LAG * ”f • /•  FIELD  •/ 

ThP’»  CALL  C3p47r_  r6vP_eCc<_F  J FLO; 

else  call  cfeatf—tewp— f c°3orcup •" 

-return; ~ 

IF  If  LJ.LE.C.Cru’P:  Pp  CC  ( T H I NGN  A *E  ) ; 

J /•  INTERNAL  TO  rwFATE.TEvp.  __  •/ 

)/»  THIS  PRCCFOijRf  Tak^S  a yfMpcp  na*E  a\C  SETS  CFAp_cLAG  TO:  •/ 

/*  T*  IF  fT*S  !i  FIELD " •/ 

/•  1 G * IF  l T • S A GpCUp  * ’ " ’ •/ 

/*  SYSEFR  IS  CALLLcO  Ic  \cithEP  IS  TRUE • / 

-OCL  THlNGNAVF  CHAR  ( LEND Th"kEyJn  AH <=T; 

UCL  STOR.ACr.°TR_L  1ST  ( pa  X.PI  OsIpFTY  ) FTP;  _ 

CCL  E_STCFAOE_FnTRI =S  PIN  FIXE0C15I; 

CCl  Ch.tPFitc  fufio  i LENF-TF_KF  Y_NAME  j ; _ OFBuG 

rp_lRFlLtalPFlLE;  " ’ ' * CEBUG 

-/*  IS  IT  A F I FL0?_ •/ 

CAl'l  "HETrteVE  f frtlNG-NAME  ||  *t  • II  !PF  ILF  If  »€4FLC  », 


start, 

ST^R AGF.PTR.L 1ST , 

*_stopagf_fntr  i ES)'; 

I F_  *,STH?  AGF_FN  rp  I C 5 r \ 

’TfcN  CO ; 

CHARGE  L AG«  • F_»  ; / *_  F l EL  0 *J 

RETURN J 

end;  _ ■ _ 

-/•  IS  IT  A GPOtlF? 

CALL  R5TPEVE | THINGNAME  |J  •£•  I I 1 P F J L £ I!  •£* GRP 


START,  

STORAGE.  PTR_i.  1ST, 

THo  AGF_E\  TF  tCSIS  

IF  ¥_STORAC6_cm to ie S > C 

T H_c  N _ CO  ; • 

~CHAP_FL AO* • C ' ; /•  GROUP  */ 

hftukn; 

E.nu; 

/•  IF  '1CITHEF  F I FLO_NCP  .CROUP*  _THEN-  CALL  SYSERP 


•/_ 


1 


#1 


-L  SYStRS  I MPIOCD  - trIElf'_C*.rPCU®:  •••  I I TMNGNAHE  if 

•••  IS  NEITHER  t G«CUP  NCR  A F IELO • ) • 

j : /•  F !bLC_r<t~czruP  •/ 

LArt_TFHP_co3.FtFl  o:  P«dC; 

J\Tc°N&L  TO  CPF  AT  F^T  6PP. 

"IN  lb  PROCEOMif  AL l CC  A TE  S AND  FILLS  A CCFY  CF  7E*P  IN  Thf  CASE 

khFkE  TmINGNAME  IS  the  name  P F _*A  _P  l E L C • 

*TfcMPS-*TFwPS*l ; 

ALLOCATE  TFMP;  _ _ 

► ILL  TcmP  WITH  THE  OBVIOUS  INFORMATION  FlPSf 

T EMP  .NAVpsrH|  NfiNANfj 

TFMP.  Tvp'e*'c  • T 7*  FIELD  •/ 

TEVP  . •♦SUGSr  P ! PT  S=  rfSuPS  ; /*  «f>  CALLING  PCUTINE  •/  

re ap. suasc® for i*suo t ; /»  ror*  calling  routine  •/ 

re  >tp.sufiscp  i pt2  = sub2  ; /•  pfcn  callinc  routine  •/ 

Tc*P. AR 1 TY=0 ; /*■  A FIFLP.  *-A$  NC  "EVQERS  */ 

.JL_C  C K U P _T  H c _$  TO  PA £,  C_  E NJo_Y  A C _C  A _TA_c  K TRY  PCP__TH_I  S_  JF£€  LC 

CALL  hfTKEVEIThjN CNA*E  I I "||  iPF  HE, 

'PLH  • # : _ . 

STAR  T, 

_ STUP  AGE_PT3_L  1ST  , 

*.STgp age.entp iesj : 

S TON  A G E _ p n * S TO  o • G c _ oj  L 1ST  I 11  ; 

cP  = STuf  aGc_Entp'y  .'ca't  A_PT  : 

FILL  rtMP  WlTw  INFORMATION  FoG«  CATa_FNTPY. 

ip  F f ?Lr*-T  YPF  = 0 thf  n TCMP. ^ATa3tvpf»»c«  ; /«  CHARACTER  •/ 

cLSb  IF  F ICLC.TYPFs L Then  Ttv0«CATA_TYor*,fS*  ; /"  B l N A°  Y */ 

ELSE  IF  c IT  LpZtyoe«2  THEN  Tpmp.c*ta_typE**n*;  /*  NUME®IC  •/ 

ELSE  _JF  F1F10_TYPE»3  THgN  Tf  y C . D A T A_  T YPF*  * F * ; _/*  F I X EC~CF  C I * A l 

~ elSc  dr: 

\»!mee3_p i c * f i e i c.tyre; 

call  sysckp(  • inner:  par  mel^type  in  field  cata.entry: 

I | MJ*‘Ppft_PfO  I ; 

CNC; 

_JF_F  rpLG.FJFJLO-LPN.TYPC^.C.jFEN  TEVP,F  I E L C_l  6N.  T Y Rfc  * • F • ; 

ELSE  it  F If  LD.F  lEL^.LFV.T  Y<>E*  l TFfN  TEMP  .F  I ELC^LEN_TYO£s  *V«  ; 

else  cr:  * ...  

NUMaEP^P  rc*F IEIC.F If LO_L  FN. TYPE ; 

CALL  S Y SEp  R I • I P l OC  C : PAD  F I flD.lFN.TYPF  IN  FIELD  * || 

•DATA .ENTRY:  * 7 | NUMpcp^p i c I ; 

_tNC  J I " 

rFMP.MlN_lENGTH«F IFLC.FIFLD_IEN.min; 

TEM» .kax_IFNCTh*f i r l d . f l f ld_ l FN.m a x ; 

KCT-Evl  TH=  NAm6S  CF  L6N  AnC~EXIST  ASSERTIONS  IF  NECESSARY. 

Cr  I EXIbT.R'^C.  _ . 

TEMP. Ex  I ST.pPDC s • »; 

ir..LTF^0.*j»SliASCPJPr.S«2).-£_lUPPg?. . .ICycCE? »,ap»  1 

Then  cu ; 

CALL  .HFTRFVF  ( THINCAA^E  ||  »66XfST  • « __  __  _ 

• ASTG*  , 

_ start,  

STC°aCc.PTP.LIST  , 

!'ST'2p  *5 F^EJS-tfi  I.6i  Li 

IF  ^.STGPAGF.FNTP ! FS  l 

then  call. sysfpp i • irtrcc:  exist. ppcc  ^issing  fcr  fielc 

THlNGNAVf  || 

...  . . • ; • •) : . . _ 

STDPAGF.OTCsStrRA  :E_‘»Tp_LIST(  n ; 

TJE M °,f  x i s T_p^ r. C»s  r.C?  A C i PJL. hA? E x U ; 

ENO; 

GcT  LcN.PPDC. 

TEMP  .Li N.R^rC* • • ; 

IF  I r EM  P • c l E LO..LE  N—T.Y  PE  * » V *.)  S ( LPP  E 3 . I CMQCC*  • P 0 • ) 


ID  CATA. ENTRY: 


EN.TYPfc* • F* ; . 
EN.TYOFs  *v« ; 


FIELD  • | | 

P.PICI; 


NECESSAP Y. 


«*»  v • * ^ 


«_STQOACF_fNTR  IE 
_ IF  R.STCRAGE.FNTO IPS  l 

THEN  CALL  ?YS6»R(  • lOIOCTs"  LEI 
TMINGNAM6_II 

• SrUPAr.F.ftTPaST^RAC  c ^OTQ  ^ 1 1 $ T ( 

Tc**P.IF'n_PROC«  STCR  A C F _ F N TRY  . N 
END;  

URN; 

; /•  CRE ATF_TFVP_CCP_F tFLO  •/ 
ATE_TtMP_FOR_GROUP~:  FRf^C; 

i m ern al” t?  Tcroco. 


T M l S PKGCenu^F  ALLCCATFS  A,\C  FILLS 
I ?.  IF:  F!XED<15I;_ 

*T£MPS**TE“PSH  ; 

ALLOCATE  Tc«0; 

fill  temp  w r th  the  nevious  inf.crmat 

T£MP.NAMF*Th  f k»/*,NA  w£  : 


re^P.  TYPP*  • ; /«  (*3C UP  •/ 

TEmp.»  jijASCR  ! t>T$*  HSUHS  ; /•  coC 

r EMP.  Su*SC:-  f PT  1 a SU°  l ; /*  FR  C 

TEF-P.SUdSC*  !PT2*5*J?2:  /•  Fc r 

clam<  c.u r that  portion  of  temp  pelf 
r?MP.CAr a_type-*  •: 

T E v P • F I FLM_L  r_N_  TYPE**  •; 

TtMH.M IN_LFNCTm*0: 

r 6* p. vax .lengths o: 
temp .LcN.Pvnc*#  * : 

IS  TncRE  AN  E X I S T_  PR  CC  ? 

Tt  •*P.F»  I S T _r*w  rc,s»  • ; 

IF  ( Ter  P.~*SUC~SCP  I P T S = 2 » C (UPFFR.I 

TntN  CL  : 

CALL  RFTRFVF  (THINCn'amE  ||  *C£ 

_ ' A S T G * f_ 

START, 

STO°AGE.PTP^L  t s t 

v_STOP  AGF’.FN  TR  I 6 
IF  R. STORAGE. ENT® »E«  -*  1 
Then  CALL  SYSCRP  ( • I C ncc:  EX 

THfNGNAMf  | | 

STORAC. F,PTR*STCRACr_pTp_L  | S T ( 

T l v P . E X I ST.PP^C * S TC^  AGeI E M R Y 
_ E*r; 

LOCK  Li  P THE  S Tno  flOF_E\ T°  Y AMT  CATA_ 
'•  TH  I NGN  A. ME  IS  GRPLPI  . . I 

CALL  GCr.GPHUP.STATE.vFNT;' 

FUL  In  a=|Ty  of  The  OS^UP  NAME. 


TtHP  #Aa  I TYsR  CCC-PP  .»Prf/P  £PS  ; 
-ECUPSIV-I.Y  G4LL  Coc  ATC.TE  VP,  CSCE 
00  [ 3 i TO  PFCGRP. rfMPMPFu 5 ; 

CALL  CREATE. If VP< S TnRAOE.FNTP 

PEf  CPP.*Sijei 

°FCG.F_r  .F  I p S T 

, ?.  EC  GF  P.S  ECT.N 

end: 

URN; 

.GPGUP.STa  TF  mENT  : PROC.; 


N.PRCC  MISSING  FOR  FIELO  •« 


Uj 

ame(I)  ; 


COPIES  CF  Temp  PCJR  A GROUP 


ICN  FIRST. 


m CALI  INC  PCLT INF  */ 

v calling  ocuttne  •/ 
v calling  ROUTINE  •/ 
V A N T GNLY  TC  FIOLCS. 


CMCCE^'RO* I 


1ST. PRCC  MISSING  FOR  GROUP 


IJ J 

.NAME! LI i 


FK'TPY  FOP  THE  STATFMFNT: 


FOP  FACH  MFM8ER  CF  TH I NCN A 


Y.MVE  <!♦  I ) , 

I ) , 

SLP ( I I , 

c_sup<  ill; 


START* 

STOe  AG£_PTP.L  1ST  , 

*_$rO° AGC.ENTR  f E S I J 

• there  A«>t  3 cases  cr  interest* 

/•  A,  l ENTRY  c C *4  6 S CACK  **> 

JHfNCNAVE  TS  NOT  A memppq  CF  ANY  CTH£t>  GROUP; 

. 2 entries  c r«6  rack  *=> 

• TMINGNAVE  is  A ME^OER  CF  ANCThER  GRCLP. 

• C.  ELS!:  **>  ERROR 

IF  #. storage. fntr  ies  IS  l THEN  set  STORAGE. ptr  ANC  op  anc  return 

IF  K_.STORAGE.ENTP  IPS  * 1 


STC0AGE.pTR*STCRACF.?Th.L  ISTIll  S 

CP*STi'°  AGE.ENTRY.OATA.pt  ; . . _ 

RETURN; 

ENO;  _ . 

/»  IF  K.ST-.P  AGE.EnTR  IES  IS  2*  Th£N  F INC  THE  STCR  AC  E.EN  T R Y WITH 

I NGN  A*  F_A_S_  I TS  FIPST  KEY_\AHE. 

P "*.S  rc°  AGE.ENTR  IFS  * 2 

thcn"co;  „ 

cc  1*1  to  2; 

STORAGE.0  TP  * stop  AGE. p tr.ustc  I ) } 
ip  STORAGE,  entry. NAVH  II  *T».  INGNAHE 
thck’  qq:  /<  ccunq  it  •/  


^ V - «0MBI 


/•  _ th  ikGnamf ; ; 

/•  c IPFILE 

/•  C GRP  _ 

CALL  kcTREVEITHINGNARE  II  »C»  II  S PF  l L 6 • 
* GP  P »* 


CR*STOR  AC-  fc. ENTRY.  CAT  A.  PT; 

_ pftijrn; 

eso: 

fno;  . ..  . ....  .. 

/•  HER?  IFF  N E !tPcP  STCRACE-6NTOY  MAS  TH I NGN AM  E 

AS  ITS  PIP  ST  WPV  NAVE  »/ __  

CALL  Sy  SF  Rp  ( • I 0 I TjC  C * C A a • • T Fino"  STOR  aGE^ENTR  Y fcr  • 

.... ...  . • The  MCOcL  STATEMENT;  •••  II  ThU;Gna^£ 

• * * IS  GROUP  I . . . );• ); 

end;  ....... 

E IFF  K.ST0P2GP.FNTP  IES  V*  A $ NEITFFP  l Nf.  > 2. 

CALL  S Y SE  3 R ( *,  I C f ? C C : CAA»>T  FINO  S TCP  aCE.cNTp  Y.FOI*  1 

i The  f'OOEL  STATF*?m;  |l  ThINGNAMG 

• • • IS  gpcup 

* GL  r.G3ntjP.S  T A TEVE NT  */ 

* ORE  aTE.TFhp_fcr.GRCU0  •/. _ _ . 

* CRFATE.TRMP  */ 

* IClCCOjy 

>('KACPO,PXTC?FtS,’*(?,72*ll,NaINrxG5N,»; 

is  P*OC<N|  RETURNS  (CHAP  ( 3 J ) ; 

[KNJI.  TO  GENT  nCC. 

S pROGEr'»*f'E  GENERATES  A\.IKCEX  VAeiAPLE  FCr  THE  INTpcEP  N, 

. PPXGFnCOI*  • 100* 

i>rx.Gi^ar^LLCU 

< E N T L Y * THE  MAXIMUM  INOEx  A L L C W £ 0 IS  N*27. 

. ... ..DIN  FIXE0II5); .. . 

SUL  T CUA?.(3)3 

T STrINGI RESULT  I EC  IT ( • I • ,N  ) _ ( A , P *99 • I . 
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RE  TURN(QrSUlT)  : 

06N  j ; /•  INOXCEN  */ 

•P«CCfcSS<  ,»'4C«0.  cx  r9Cf.fSM,(^f  72,  J ) f N*  PACK  •); 

PACK:  PRCC(NFXT_lNOr X)  PFCURSIVE; 

/*  EXTERNAL.  TO  C f N p c A r F _ P A c K INC. 

OCl  N£XT_|.\frEX  dIN  FIXFD(lS);  /•  THIS  PARAMETER  TCI. US  US  WHICH 

• __  /•  IS  THf  NFXT.INOEX  TO  US  E IN  A 

~ /♦  CC-LCCP  CP  FCR  SUBSCRIPTING. 

OCL  NSTK  dl*  PI  X E D ( L 5 > EXT; 

OCl  ptr  pointer: 

OCL  PACnFLO  f N T k Y ( p I N FlXcC< t 5l  ) ; 

ccC  packgVp  ENfqv'niN  FixEciisn; 

OCL  SYSCk*  EM  p Y 1 CHAP  ( * II  ; 

CCL  FTR.PTR  PPINTEp  EXT; 

5CCL  LEN.CIC T_CNToy  FIXED:  TL FN_C  I C T_ EN T R Y*  3 2 5 

SCcl  max_l_name  FixEC:  *hay-l.\a^e»  l c ; 

_ YCCL  L?NGTh_kCY_N4*E  FIXFO;  f L F \G TH_ KF Y. K A » 10 ; 

I IN  C LUO e dCLI  ?T(FfP  ) 5 
P T fts  F Tk  _p  T°  ; 

nstr-nstpm: 

IF  TYPF(\'STP  )«»F*  THC  \ CALL  P AC  K F L C ( NE  X T_  I N 06  X I ; 
cLSE  IF  TYPMNSTR  J»  • C*  THEN  CALL  PACKGPP  (NFX  T.  INC6X  ) ; 

ELSE  /»  TY°f  I NS TPJ_f  SN  • T »F«  CP  *C-  • . • / __ 

CALL  SYSERM  •GEMPCP-paC  <:  ILL  B C At  TYPE  •*  || 

TYPE (NS T 3 | | | 

•••  FQR  SUBSTRUCTURE  NAHEC  •••  II 
nameinst®  J | | 

••••); 


• / 
•/ 
• / 
•/ 


Algorithm 

PACK 

2 


return; 


•POCCcSS  ( 'MAC?  cXTPEF  ( ?*  7?  1 1 ) tN*P  'CKFir  • ) 5 
PAuKFtO:  F*1C  CiE  XT-IMEX  ) ; 

/•  EXTck.NAU  T0  pack.  •/ 

/•  henF^at^S  cnnF  r-C*  pac<  InO  f i ELCS. 

/ « Jhc,<£_  AkJ  _T  A_Sf  s of  interest: */ 

7«  * ’ * sue  sc*  iprsiNsfp » * o ""  ”•/ 

/*  _ *SL2SCPIPTS(NSTP»  * I */ 

/•  " rfS'JHSCPI  PT  S (*STO  ) a ? •/ 

OCL  NcXT^lNOEX * IN  FIXE0C15|;  /•  THIS  PAOARFTfP  TELLS  US  WHICH  •/ 

/»  is  the  .\fx7_ index  to  usf  in  a */ 

/«  CC-LCCP  CP  F CP  SUflSCP  I o T I NO*  *J 


CCL“NSTK~pin  FIX  = rflS)  EXT; 

CCL  <fRrO*IAME  CHA702)  VAQ  Ext; 

CCL  RRECSTklNG  Cl  4 A " ( 3 <• ) VAR  EXT; 

CCL  PLiSTu  FH ap 1320)  VAR; 

OCl  pTk  PUINTEP; 

LCL_  SY  Sc  R'<  ENTP  YICHJ1IM  > J 

CCL  HYTf-jC.ALC  PNTPrlRfM  F f xp0  ( 15)  *CH  6°  f l } f 6 IN  F fxFC  ( 15))* 

OCL  SUrtSC*  I°T_STk  PIG  F.  *IT°  Y of  TUP  NS  ( CHAP  ( ICC  ) VAR);  

CCL  FTo.PTk  Prf\TCP  EXT; 

^CCL  LSN.OIC T.^TCV  FfxcC;  SU  CN_C  !C  T_  ENTRY*  32 ; __  _ _ 

<i)C L max.l.ma^f  fixcc;  y^ax.l^namp* ic : 

XCC  L L E hC,  TH .K E Y . N A^F__F_I_X_E Cj__  ?LFVCT H_Kf  V_N AJ^f^ljO £ 

® 1 N C LUO ? IN Ct  I ° I FTP  ) ; 

OCL  PLSr.STK  ENTPYIHIN  FIXECIISI);.  _ _ 

OCL  PCPSTK  fnt°y; 

OCL  dfcPLl  ENTRYI  CHAP  (•»)  VAR  , CHAO  (*))  ; _ 

CCL  l.NOXGEN  f[NToy(UM  FrXF^(lS))  R F T UP  N S ( C H A R ( 3 I ) V 

_DCL__PIC  TUkE  F'lTPVI  A f N f IXEr  (J  E ) I P E r L P N S I C H A o ( IQ  )VAP); 

C CL  C HP  T k L k”  o N T R Y f C H A c ( «)1  Pgtu’PN'S  (CHAP-  ( 32)  'VAR  ) ; 

pffiic  r«_OTJ ; _ _ q 

: IF"*SIJfl«CP  i PT$  (NST'f  | s ”c  ~ J 

, __  THEN  OH; 4 
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CALL  aeKFUATe-rCVt-lKSlRSt 

a ETU«N ; 

PNCS  

ELSE  IF  tf$tJ3SCarPTS(NSTR)  » l 


CALL  PUSHST«(NEXT_|NC6X»;  • 
PllSTP.'DO  > || 

t 

INCXGEN<NEXT_INCEX|  II 

•*i  rn  • ll 

£ PICTURE! suesc? IPT1 (NSTR)I  || 

• ; • ; 

CALL  CENPWATr^MCVF.rNSTRS;  

«»L  istp**enc; • ; 

CALL  wqpl  l (PL1STR  f * PL  IFX«  )j 

CALL  PDPSTK; 

RETURN; 

ENO;  - 

ELSE  IF  MSUHSC«IPTS(NSTP>*2)  £ ( SUPSCP  !p T2 (NSTR I * 1 1 . 0 

then  do: 

__  _ PLISTP.'OC  • ||  ...  

!NOxceN<*.fxT_iNcex)  II 

1M  J c_f  x 1<  T 1 

CHOTRLPINAKE (NSTRI)  || 

l ; • • 

Call  W6PI  I tPLISTP,  »PLIEX»  ) ;" 

CALL  gfneo atf^movf.  instps, ... 

pl  i$T*«  »fnc : • ; 

C A LL WR  PLJ  ( nL  1 STR,  »PLlgXM  ; 

RF.  TURN; 

PNC?  .......  7 

ELSE  IF  *S'»eSCR  TPTSIASTP ) * 2 r 

THEN  0^;  _ _ 

CALL  PUSHST»<(N6XT.INC5XI  ; 

PLisrpajon  • ll 

INOCEMNCXT.INCEXI  || 

....  * * I rn  EXIST.*  II  __  . _ _ . 

CHPTRL8INAKE INSTP ) ) |) 

• j • ; 

CALI  wopl l (PLISTP  , «PL  1FX* | ; 

call.  CEr  z.  ? AT  F^C  v f LbSTB  S ; 

, pl ISTP* • £ \ C ; 1 ; 

_ CALI  wpPL  KPLISTP,  *PLIEX*1  ; ...  

CALL  POPS  TK  ; 

pftupa'; _ ... 

5NP ; 

ELSE  /•  «SU»SC^  IP^SIASTP)  iSN*T_C_QR  l _C°.  2. */ 

CALL  SYSFRP  ( «Gc**roCn  - PACrfPlC:  ILLEGAL  0SUOSCMPTS  • II 

....  PICTURE!  *$uescf<  I°TS  (NSTR  ) I II 

• FCP  SUPSTCLlCTLRf  • • • II 

. ...  NAME  INSTP)  !|  _ 

***'*•  Algorithm  GEN-MuVt;-lNSTR-POR-PArjrnL,^ 

vFPATfc  MOVE  I»lSTeS:  por»C: UK  PACKING 

INTERNAL  TO  PACK^FICLC.  •/ 

This  PPOCFOtjP  E GENERATES  TPP  PproFP  INSTRLCTICNS  FCR  ^ */  _.  _ 

CATENATING  ChaoactFR.  BINARY,  OP  f I XED-C^C  I VAL  INFORMATION  • / 

CNTC  TFE  OUTPUT  STPING. . ...  •/  

L «*YI6S  ft  IN  PIXFCC  15)  5 . 

If.  f A T Y P E I vj S I R ) .•»_ ' C, * 

Then  no;  - 

PL  l STP*  #0  £C  $ TP  ING-  l.l ..  - 

• * • II 

IPECSTPING  ll 


•PeCNAKE  II 
• 1 1 

CHpTRl«<NA*e <NSTP n II 
SUR'CR  IPT  ST*  t\c  If 


CALL  WRPl  l ( • CL  LEX*  ) 

RETURN;  ~ 

• E*n: 

£lse  if  oa rA.TrpecNstff i»»e» 

THEN  OP; 


r^proLe (NAve ( VSTR | | | | 
S'JflSCR  IP  T_STR  1NG  I I 

• I ; « : 

CALL  WPPL l IPllST? , • PL  1FX» ) s 
=»  FTURN; 


ELSE  IP  nATA.TYPE (NSTP 

THEN  pH; 

° L l<TR*«PcCSTR  ING  I I 

II 

PPfCSTP IMG  I I 


ARECNAME  II 

• . ' II 

CHOTPLe(NAHp(NSTR ) » || 

SU*SC®M>T  STRING  II 


CALL  WRPLl(OLlSrpt»PLlEX*|; 

0 F TURN ; 

FN'C; 

ELSE  IE  OATA^TyPf (NST3 ) * • F • 

TmFn  on: 

CJIL  »VYTF-CALC(-  IN_L  ENCTHI  NS  TR  I ,JB  AflYTFS) 

^L  l STM*  RR  FC3TS  INC  II  " 

_ _ • * • II  __  „ 

AP EC STq  INC  II 

' I I LNSPFC  I • l| 

APECNAVE  II 


CmdTdl»INAV= CNSTR  | ) || 
SftfSCer  PT~S  TO  i\c  || 

• I : • ; 

CALL  WRPLIC®LISTR, »0L16X« ) 

PE  TURN; 


ELSE  /*  C A T ry  PP  < *4  S TP  I f SN  * r *.C  • fo  "J  * CP  *F«  • •, 

_ CALL  SYSERPI  'C.cNIOCn  - PACKFLC:  ILLEGAL  CAT A—  TYPE 

OAT  A. TYPE INSTr ) I I 

__ _ •••  IN  SUBSTRUCTURE  NA^EO  •••  || 

NAMFINST4)  I | 

"END;  /•  GE.N  EP  Ar  c-.NnVEw  I NS  TP  S •/ 

SM; ; /*  PACK^Ffcio  •/"  ^ _ 

PrtLbSSI  • N AC°P  * E X TP  £F  , s»<*  ( ? , 7 2 1 1 ) •N*0aCkCPF,|  ; 
paC^GHP:  _ P«pf  ( N?  XT^If.nFx  ) RECURS  | VE  5 


Algorithm  PACKGRP 


■<  ' x, 


ICC  L L EN.O  I C T.EN  TRY  riXEC;  *L  EN.CIC  T.ENTR  V » 32  5 
tCCL  MAX.L.NAMg  PIXFO:  t* AX.L.N AME*  10  ; 

ICCL  LtNOTH.KfY.NAMf  FJXFO;  _TIE  KC.TH.Kg  Y.NAH  f»  10  ; 

/•  tXlEkNAL  TO  PACK. 

/•Of  KZ  RAl  tr  5 COOf  FC°  PACKING  A C PHIJP  ANC  CA  L L_S  _?  ACK  FQR  J ACM, 
HfHHCK.' 

THtRQ  ARE  3 CASES  CF  INTEREST: 


/ 

/• 

/• 

/* 

/• 

OCL 

OCL 

CCL 

OCL 

OCL 

OCL 

OCL 

CCL 

CCL 

CCL 

CCL 

CCL 

OCL 


«$UBSCPIPTS(NSTR)  . 0 

«SU?SC°IPT$CNSTPi  - l 

*SL'RSCR  IPTS  (NSTR  1 • 2 

N6XT.JNCFX  PIN  FI X6C(  15)  ; 

LUC-L.AHTY  PIN  F | XFO(  15 1 • 

N$TR  BIN  FIXfCI 15)  EXT; 

PLlsro  Chap ( 3?0)  VAR; 

Ch^TkLS  5NT»YtCHA«M  •)  ) P f TU°  N S ( C F AR  C 2 2 > V AP  ) ; _ 

P-CK  entwymiv  FlXECllSL); 

P 0 Sm  S Tk_FN  Ta V(P[N  F 1XFC ( 15)  ) ; 

PCPStiT  EH  TR  Y ; 

INCxGcN  FNTRVIBIM  FlXPnns))  »F  TURN  S ( CM  AP  ( 3 ) ) 5 
PICTURE  cNTRY(?|N  clxeni5)>  RFTL'RNSIChaR  ( 1C  )VAR  I ; 

* R P L l cNTCYT  CHAP  C •)  VAP  #CHAC  < • ; 


♦/ 

_•/ 

*/ 

V _ 

*/ 

•/ 

*/ 


SYSFRR  5 NTH YfCHAP (•  I I ; 

FTP.PTk  POlNTfA  P X T ; 

TlNCLUJt  IliCL  I 90  C FTP  ) » 

CCL  l e IN  F I XFC  ( 15  ) ; 

o ff.  *F  Tp  _PTR  ; 

I f”ksha$cp  I p TS  ( N<  TP  ) _*_  p 

Them  On; 

IL1CAI_APJLTY*AR  I TY  (NSTR  ) ; 

o?  i*  i tc  IccaOp  i r y : 

__  CALL_PACK(\6XT.I\CEX)  ; 

ENO; 

..  return; 

cmo  ; 

EL  bc_IF  xs«laSCR  IPTSI  NSTR  ) » 1 

THEN  nn; 

Call  PUShSTk INF xt^incE >) ; 

°L  lSTP*‘On  • | | 

_ INCXCFNI VFXT.INCEX ) II 

•*l  TO  • II 

auciLif j ikfj  ca  t eiujv  sir  > u 


10 


11  12) 


CALL  WPPLKPL1ST?  , *PI  IEX' ) ; 
LOCal.ap  T 7 V * A P I T V I A.'  $ T R ) ; 
on  i*T  jr  lccal.ap  i ty; 

CALL  PACK  I NEXT.  INCEXM  ) ; 

_EV.n ; 


?L  1STP* • ENC ; • ; 

. CALL  OP°L  lIPLISTF  »*PL  IEX' ) ; 

Call  PCPSTK; 

> E TURN L __  

end; 

ELSE  IF  <<;uqSCFIPTSriSTP)«2l_&._{SUg.SC»lP.T2  (Nil*  J « U- 
THEN  005 

PL  IS T P * • 0C  *11  _ . 

irnxGr/MNFxT.iNCExi  ti 

* * l TO  CXI  ST.'  ||  . 

CHRTRLP(NAHffNSTR) ) || 


liU) 


call  VIP  PL  l(Pl  ISTP  **PLl£X»  >5 

...LOCAL.  AO  I TY*  A«  I TV  (N$  TR  | ; . 

OC  1*1  TC  LCCAL.A®  I TY  ; 

-CALL- PACK  (NEXT.INCEX*!)  * 


4 
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•®RQCE SS_( 'Ni T ,M»C^C*N- lOGCTC*  ) ; 

■"ir>uC  rc:  P»JC5  ~ 

XCCL  MA  a_LE  N.L  A "if  L F_I  X EC  • 

xmax.lcN.lahpl* l«; 

CCL  l PLOW  r AP.PPO  To  SASEC(P>_t_ 

2 node*  f \ xeo  * in  f 

2 T Y°  E CHAP  JO, 

” 2 LArtEL  chad  (Vflx_ie^_LAP  EU  ; 

L’CL  C\[VLA°  CWAQ (max.LEN.LA6E U VA»  EXT; 
LOCATE  FLCWTA8.PPCTO  F I LE  ( F LCW  T AC  ) S 

NC3E«*0:  

T YPr  s,r»OTn*  ; 

L AC? L « OP  f VL  A6  ; 

E»\i*  Ibcurc; 

• psr.  c t s ^ ( * ns  r • acp c • n » i o-ocnm  «Tr 

fOPCGMC  PPCC (OICT# I ; 


/•  THIS  PP'JCCOUPE  CREATES  a FLCWCHAPT  »€Cr°C  FCR  PCOULE  NANES.  •/ 
JlNCLUPh  INCL ! ^(COICTI; 

/•  THE  «cCP°?,  •/  __  _ 

JCL  l F Lc.  H r A P.*‘nCL  9A  SEC  ( FLCV.TA0.MOCL.PTP  1 » 

2 *'C0 c*  cjx£0  «!>:, 

2 .NOr>pJ TYPE  Cmap'U), 

2 ^COrJLS.NAHE  CHAP(lO)r_ 

CfCT#  F IXF.U  PIN; 

/•  CREATE  P^CHP".  */  _ 

LOCATE  rLC*T  Am.  'GOL  e IL E ( FtO* T A b ) SFT(FLCWTAB_MncL.PT»>;~" 

MCCEXaClCTt;  

NCCE. TyP  = = * POOL • ; 

MCOULfc.NAMc*ClCTCOtCTP|  x 

RETURN; 

END  IOMOO.NM  ; 
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•p  fi  n C e S SJL*_N  S J.  Sm  * ( 2 t 72  t 1 ) iNalDWS  FT  , H ACRC  * ) i 

ICkSET:  PkCiC; 

♦ INCLUDE  INCL  IS CCCJCT ) ; 

ICC L MAA_LtN_NAMF  FIXED; 

ICC L PAX.tEN.5NM  FIXCO; 

ICLL  NODES  FlXEC: 

**A  X_LEN.C<N»  -32; 

” IMA  A *_CbNn'_Nl’°ES=  30; 

If*  AX_L  EN_N  AME  = 1 0 ; 

DC L i FLCWT\e_RScT  3ASFC(P). 

2 NODE*  FIXED  SIN, 

2 T Y°F  CHAT  < A ) , 

2 N A M E CHAR (MAX  _LEN_CNM| ; 

xincluoe  incl  isccsysfcnT; 

CCL  CCiNC  A S ( MAX  1_CCN0_NGDC  S ) CH AR ( * AX.LEN.N AH E ) VAR  E> 

/*  the  'COCOAS*  <cn\crrrnNAL  assertions!  taplf  chkt&i 

OF  ALL  The  ASSFoti^nS  WHOSE  COMPLETION  IS  CCNCITI 

3 Y MDASSN*  */ 

_ CC  L. _»COND  A S_F  ? X c n P.  I N F_X  Tj 

0/*  PFSff  ALL  “uV-TI.mp  CC\0  ! T 1CSAL  FLAGS  */ 

DC  K*L  rr  ifCONOAS;  _ 

LOCATE  FinwTAB.RSFT  P I L E ( FLOW T A3 ) ; 

F LrJWTA  J^R  SET  •NQCF  1*0  J 
Ftrw  TA»«_P SFT. type*’ R SET*; 

FL^WTAS  ^QSET.rfAME-cc^QASIK  ) Lll-C  CAPLET  EC* ; 

6NC  ; 

-/<*  IF  THE  rf^UCF  FUNCTION  WAS  CVF°  LSET,  P E S E T THE  RUN-1 
•WASkEPL'  , *F  tasnCPL*  C THE  STACK  INDEX  '«STACk»*/ 

IF  USEFCNdl  THEN  /*  USED  TF£  •REPLACE*  FCN  •/ 

oo; 

LCC  A T E _F.l  CN  T a P_R  S E T_FJ_Li  ( FLCWTAB  ) 

PLJWTAP^PSrT.NnnEKsO; 

Flow  T *.S_k  SET.  Type*  • PSFT*  ; 

FLOW! At_PSF  T #NA-F»* WASPEPL  1 : 

_ LUCATF  FLONTAB^RSFT  p ILE  t FLCWTA8  ) ; 

flout \3.rset.ngoei*o: 

FLO  TAB  . PSCT  . TYQE*»PSFT»  : 

Ftr.WTA8.e  SF^.N^‘*?*•ALPC^?L,: 

, LOCATE  FLOWTAE.RSET  F f l E ( FLCW  T 46  ) ; 

fl'iwtap^q  sct  .r-'cnr  1*0: 

FLC  H T SET, TYP£  = • 0 Sf  T * ; 1 

FLOwrA(i-:‘ScT.NAVE*'1STACK*; 

_r/*_  AL  S':  _F  E S ^ l 1.  L . CHOICE  h/»Mf  S *1 

coo  j*i  to  oicrr’-n  whii  c (c:r  m jx,rH:  \ce.unz*  i ; 

.IF  LENGTH! D1CTI J>  ) ..  >7  ^H£^  IF  SL3STR  (C  ICT I J) » 1*71  = 

THEN  DC; 

LOCATE  FLCWTAE^PSET  F ! L E ( F LCW T Afi ) ; 


xr: 

INS  the 
ional;  f 


U.NES 
ILLEO  UP 


FLOwT A P^R s ET .NrrE 1*0 ; 
FL0WTAP_PSET.TY^>F*'PSET,  : 
FL0WTAH*RSCT.NAVE*CICI ( J)  ; 


end; 

-FNC  I DP  SET; 


i 


wpppi 


• process! *n$t ,sm*! 2. 72 ,i i ,n*ff«cpl  i ."acfc* i ; 

Ht^CHLls  P*CC; 

/*  (HIS  PKJCFru0?  MERGES  the  PH  CCCE  TILES  INTC  ONE  PllPPOG  FILE*/ 
(XL  PLISrc  rHA<M*C>  BASEC(P): 

_CC  l !_P  L_L  DC  L _ E rr  . D L l Of .EH  F , P L L E X_FT  F t P L lPPCC.fr.f  ) e IJ  ( JJ  I N IJ  (_•  0 • ft)  ; 

DC  L T c“ <Y> l’  c‘  “7  T'(  l )‘  I nTt  ( • 0 • H IT  ' 

OCL  F iLfc.Tc.  X T.NAPF  CHAP(IO)  VAP*._ 

OCL  tXT_E*'F  .1 1 T ( l ) IN1M»0«P); 

CPEN  f ILK  °L  IP^COPUTPUT  pECORC  SEOL.  

FILE  ( PLIDCL  ) INPUT  *FC”PO  SfCL. 

F ij. e ( P L l n.\  i ! n pu r_a  E C" w c_S  f c l^ 

F~I  LM  PL 1 E X I I NPU T a Ef>P  0 SEOl  » 

F ILC  (PL  l°PDC)  INPUT  PECCPJD  _SEQL  S 

XIFCLUOE  I\CL Itt(PSYSFCN)  : 

-/-CL  PY  DECLARATIONS  F T LE * / 

UN  ENOMLEI  PL  IDCL  )Pl  lCCL_cOF=  • l ' 8 5 

_Rcac  filE(pliocdsct(pi  : * 

DU  - Hi C F ( -PL fnc L.ECF ) ; 7 

/•FITE  r ILF(  PL  IPPTG)  FROM ( PL  ISTP  )J _ __  

READ  FILE! AtiDCL J SETIPJ; 

ENO;  

-/•  COPY  PLICN  file*/ 

ON  E-NCF  1 LEI  PH  ON)  pl  lCN_Ef"g-«  l »?; 

fife  Ml)'  fi!L£TPLlW)  SET(PlT 
CC  WHILC( -p LI CM_ EOF) ; 

«RIIc  rlLE(PLl®PCG)  FRO^(°LlSrP); 

FcAQ  FILEIPLION)  SET(P);  _ 

END; 

/ *C  CPY  PLIEX  FILE*/ 

C N i\~j F I L 5 l PL  1 F X T 3_L  1 E X _ EC F » • f *8  ; 

R=AC  F|LrlDLl£X)  SCT(P>; 

00  WN  tl- ( -u'.  lcX_ECc  I ; 

*’<  I T c F TLE( Pl  IPOFG ) c °0M  t Pi  1STR)  • 

R 6 Ai)  F l L c ( °L l cX  ) SCT(P)  ; 

cNO  ; _ 

" OU'”l*  r Tp'-SYSFCn  ; 

IF  USE.FCN  (II  r HEN  CC  J 

F II :_rcXT_\XME  -FCNTFxr ( I I ; 

rex r_tL f -r 


CPtN  F ILFI  TPXT)  INPUT  3 F CO  0 0 SFO».  T I T L 6 ( F I L E.  T E X T.N  AM  f ) ; 
Of-;  tNwr  ILc  C TEXT)  TcXT_tOc 

3 E AC  F I L E ( f c v f J SET  ( P 1 ; __  • 

CC  WHILE  l-TcXT.ECc)  J 

wR  I r e r IL  c<  »»l  IPfGC)  ( P L l S TR  ) ; 

k E A* >~  FILE!  TEXT)  SFT  IP  ) ; 

EMC ; 

enc; 

Close  fileitfxti;  _ __  _ 

END; 

-/•  copy  cTht?  ° un r i y f 3 cl. r imf s_* / 

CN~  EM)r  I L C < 5 UMT  EXT  ) RI.'McXOcF  * • 1 ' C ; 

RFAO  FILE (RUN TFXT)  SET(P); 

CO  WHILE!  -»3  I'M  T CX  T_  en  F I ; 

WkITE  f i lE ( PL l PPCC  I FPTMIPL  IST3  ) ; 

RE  AO  F ILF! pUNTFx T)  S£T(P); 

EMC ; 

-/Vccpy  plTprtc  file*/ 

ON  r\LFI LF (PLIPPOCIPL IPRCC^EOFs* t »e; 
wEAO  FILE!PLI«RC1C)  SET(P); 

OC  WHILE ( -P L IPPPC.ECF ) : 

WRITE  HLF!Pll?PCGI  FRO * ( PI  l $ TP  ) ; 

P EAU  F ILC! PL  IPPfC ) Sct(P); 

EMC; 

OC L La c F ILEtPLlPRCG)  ; _ _ „ __ 

-ENC; 


*au»***' 


‘j. 


3 
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•PMiCESSI  •NST,SMst;>,72Pl  | .NaPRfCFC*  ) : 

PRSCf  67’P^CC  * OjMAf,  OkOEP  t N): 

/•  H»A*AN  6b  SCO  ES  TP  A CIRECT  CP  APk  I SPbC  I F I E 0 H Y ACJACENCY  MATRIX  */PREC  01 
/•  "AHJMAT",N  PY  M In  ASCPnOINC  "OINK"  CRCE®.  RESULTING  IN  N-ELEmFNT*/ 

/•  vector  "O® pf»m.  •/ 

CCL  ( AJJN  AT  ( « , • ) # UMJSEIN')*  T INlMM'e).  F IMU'O'R)  I BITC1I. 

1 3K0Eg  I «)_.NnofcS  {?  I [‘MM  ( *101  .NEW  J\  rrm.CLO  ISIU  DiFlXED  9 1 N ; 

"ocl  "c  p^thi.’.n),  k imtTc’j  I FIXEC  e I N ; 

□ CL  rUNK(NP)  FlXrC  BIN  EXT  CTL;  _ _ 

UCL  (I.J.L.II.**)  FIXFO  B I M STATIC;’ 


/•  AC  JM  AT  — ADJACENCY  MATRIX  DEFINING  THF  CICRAPH.  _ */ 

/•  N T*F  N'JNrfFR  CF  VCPF  S In  ThF  c I GRAPH*  *"  ” */ 

/♦  CkOCF T«=  VFCTr;  rP  \r.C6S  I N RANK  CSCE®.  • / 

/*  r AUK VECTOR  PF  BANKS  Oc  NTFS  IN  DIGRAPH.  INTUIT  IVEL  Y,  THE  */ 

/« IS  Tnf  N*X.-PCPT»-  OF  A r.IvFN  NCOF  IN  THE  DIGRAPH  •/ 

/«  F'b  O.v.  any  PCPT.  EXT  ^ECAUS'E  USEC  In  'CFLTOOT*  ~ */ 

/-  DEPTH- — Sc  T QC  NCDES  in  a GIVEN  PANkICLC  t NEW),  I.E.,  "RANK  SET",*/ 

/*  N'jOfeS Cnur:Tcas  F pp  a QF  N»jOF  S IN  CLO  G n£H  RANK  SET(CEpTH).  • / 

/*  CLO PCINTEP  TH  P°c VITUS  FANK  SET#  */ 

/•  iN E M PCIMER  TC  CliP E CM T Rank  SET,  • / 

/*  UNUSc °I  r VECTCP  OF  ACQFS  NC  T fN  THE  C'JPP  F\  f RANK  SET. */ 


0/«  ALLOCATE  =Ank  and  INITIALIZE  RANK  CF  ALL  NODES  IQ  0 ♦/  8 

0 NRsN;  

ALLOCATE  Rank; 

0 k AN K , CROC®  * 0;  _____  9 1 

/•  SET  UP  f>fcpTH  C.  •/  ’ ” 1C 

CJ_J  = L TO  N J l JL 

/•  EnTE?  T h S E NUDES  with  AN  ALL-C  CCLUVN  IN  THE  FI®s"T  RANK  SET  */ 

I F ANY!  AUJMAT  I * , J ) ) TH^N  r.CTC  CUT  ; 12  2 

NCOtSl '’LUJsNCJESIfJLD  ) ♦! ; C6PTMCLC  »*M  *4;  !3 

CUT:  END;  _ 14 

0 IF  WOO?  SCOLC? ><*0  T n c \ n’CTC  ?bo;  /*  NO  COL  has  all  0 •/  15 

/ * WHICH  vc  Af.  s T ° A T = vE°  Y TH  I»G  J $ 

dependent  on  something  elsf  •/ 

0 /*  I.ITHERWISF,  PPDCkEO  TC  Ft*ir  u ANK  SETS  CF  i;F°TH  l A N C CN  •/ 

0 CC  L-*l  TC  N-i;  /•  FOP  EACH  b i*.w  SET  ("Cc P TH«|  •/  17  ^ 

/•*  ir.ITlALI?6  NUMqcp  CF  ‘CD  F S IN  NEXT  BANK  SET  TC  Cj  * 

FLAG  *LL  ■iCr'CS  AS  Nr  T APPEARING  IN  N F x T RANK  S F T INITIALLY  •/ 

_N.qCE5  ("rw unl S F_f_r La 

0 o’u”l*i  K.J  E si  CLO ) ; ’ II  *CFPTH(CLCn  ) ; /•  PC®  each  ncce  'in  THF  5 


PRFV  IDUS  ? AN  K SET  •/ 

0 00  J*1  r C n;  /*  FC5  Each  COLUMN  ( n C ^ 6 I Chcc.k  fc  it  is  a 

OF o • \Cr N T OF  NCCc  IN  OLD  0 ANK  SET  •/ 

0 /•  IF  NOCE  IS  CFPENOrNT  CF  CU*'RF\T  f.CCc  IN  CLD  RANK  SET 

( \ ^oe_ i r a'  q_  r f_  rr . i s not  YfT  ine*>  rank  s^t 

T HP':  ENTF3  IT  AS  A 'ye'f/ac?  r F THE  NEXT  RAN*  SET  */ 

IF  ADJ  v a r { f I , j | fF  »r*;u9ff(j|  rnF'; 

PC;  PAf;K(j|aL:  ’JNUS e I J ) -F ; /•  SET  r«  ’J°hatE  bank  CF  NODE  6 

AND  INDICATE  that  it  IS  NO  a RANK  Set*/ 

M,  NCDFSCNrW)  aNOrFSI\cW)  ♦!;  DEPTH  ( NHVf  ,P  )=  J ; 

~0  ? * 

p%,c; 

0 /*  IF  TMF'JF  APF  NOT  any  N Of)  f S IN  NC>T  BANK  SeT,  |.F,  THERE 

AC*c  ho  NCQES  0E°  FN'PHN  T CN  ANY  NCCES  IN  PREVIOUS  RANK  SET. 

DHTN  VF  Ao  e CC*’c  PfCAUSf  cVFPY  NCDE  haS  ITS  RANK  */ 

LF_fj  ) nf  s r) E> J^=_C _J H C N GOTO  3ECHCFP; : 7 

0 /*  E a DMA  NO r ^Lr  ANC  o^k  SETS,  WHICH  mAS  THf  EFF  rC  7 OF 

MAKING  RANK  SFT  THF  CLO  CNE,  AND  A NEW  "NEW"  RANK  SET 

WILL  C R C A T c C IN  NEXT  PASS  */ 

m*n£w;  m e w * r l d ; clo=m ; 

END; 


-  w : 

RcTjWN;  /-CYCLES  DXlST.  ?oocp'ocTt?N  w I TH  OPrfTaC  •/ 

- n.;k»:  /»  SCOT  a;  00  c S TY  ASCFNCJNG  RANK  CPOEP.  •/ 

CL  I«0  TC  L-lS 

CM  J«  1 T? 

IF  ® AM< ( j | • | Then  00;  k«k>i;  CflnHPlK)»j;  FNO;  34 

• ?lt£lr*j 


/•SYSTEM  "REPLACE"  FUNC  T t CN»/ 

_R6 PLACE  5 PROC ( G, N) RETURNS 1 CHAR (20)VAR)  ; 

DCL  6t*t  CmARIM! 

OCL  1 F 1X50 _8IN{ 

OCL  N F IXED  BIN; 

/•  IF  THIS  FIRST  TIME  LIST  IS  GIVEN  TO  'REPLACE'.  STACK  IT  */ 

IF  - AL  R R E PL  THEN 

DC; 

alrrepl * • i*B  ; 

0 ST  ACK  = N;  

PUT  SKI P LI  ST  ( 'STACK'  , G) ; 

PUT  SKIP  L 1 ST  1 tSTACK)  ; 

00  i = l TO  dSTACK; 

J ST  A CM  « SJ  AC  K+I-I)»G(I)» 

enc; 

ENC ; 

/•POP  LP*/ 

«asrepl»'  I' 9; 

IF  » S T ACK  <1  THEN 

Do;  

cfo ice . Empty  = • i's ; 

BET  URN  1SSTACK  11)1; 

END  j 

CHO ICE . EPPTY=*  O'  9; 

*STACK=#STACK-IJ 

RETURN (JSTACK I# STACK*!) );  /»  RETURN  TOP  OF  STACK  •/ 

ENO- _ 


•®PCCtS5<  •*ACP?.N$f.  CXTpPct\*,ftPTPFVJFjJ; 

~ *EI  f * V - : r»  itlf.PTl-'  M LLGir  il  ,cc  \ I ^oi  , < r ART  ,~a  t TPTO  $ ) ; 

/ • u:cuh  rs  4 «t*inc  ?f  na-cs  umtec  e y logical  expressions  • / 1 U6 

/-  CCNTCL  is  a STPl\C,  USER  P^e  CHECKING  the  cata  •/  l 116 

/•  s r a r gives  the  f i s r oirec tcp y.entpy  */  l U6 

/•  t-ETPl^S  IS  TUC  ARRAY  CP  POINTERS  SATISFYING  THE  REQUEST  ITT  ?E  PILLEO 


bY  • j46T9FV**I */ 

/•  M IS  It-:  NU-lfR  C F EN>  3 I b*  S IN  Tw£  RFTPTo’s  ARRAY  ; I . F • TH  E NUMBER 
'.IF  ENTRIES  SATISFYING  Th?  ofCUBST  */ 

OCL  ( Lnr' ICAL  fCCNToCU  ChaR<*); 

* CC  l M- <-LFNGTH_^ATrtS TR  F { X E C ; __ 

ICC L 8A  x.lcV.ARR  AY  FIXcC; 

r^ax  LcNGTH  OAfASTRMCC: 

*».%  x.len.akR  a y*  lco  ; 

•KL  0FT3r0S(«J  PnrNT6R;._  _ _ 

CCL  M F I X CO  RIM  ; 

CCL  WTFKARR AYILfN.wrRK. ARRAY)  PC  INTER  C Tl ; . 

/*  WUNARRAY  IS  USFO  F CR  TFMPQ^APY  S TCR  AGE  •/ 

c c l _s  i gn_jli  K.i )_ ; 

CCL  START  p'c  INTER: 

ilNCLUPP  INCH  ?.  enSEO  IP  ) ; 

CCL  FIXEC  afMAPY; 

/*  KK  l 'Aii  l C A T P S THC  Cl'®  R 6N  T NAMC  I\  LOGICAL  WHICH  IS  PROCESSES  */ 

/*  Gives  THF  NMMRCR  CF  LCCATIC^S  IN  v,C»*ARRAY  THAT  ARE  FULL  */ 

0 C L !_I  c A_ C M A o ( L.PN QT  H_<  S Y \ & y f | ; 

/•  I TE“  I S Th=  *PY.NAMr  ANALYSED  */ 

CCL  SYMBOL  ”r  r«  Ar  ( 1 ) ; 

/♦  SYM  *01  IS  USED  EC®  CHECKING  LCOfrAL  CPCRATCRS  •/ 

/•  ALLOCATE  •'.t-  >K  fijc  AY*  with  S A>4E  M/M  0 p P Cc  ENTRIES  A S RETPfRS  */ 


LE'l.WQ-  K.A«P  A YsH.3rUNn  (RE  T®  T*  S • l J J 
I.  L re  ATE  W«~*  F K AP  R A_YJ 


G6T.NA.-fC  : 

I TE  " = SUQ  S T ^ (LCSI  CAl.  ,<<,  LENGTH. KEY.  SAMP)  ; 


/•THE  FUST  kT  Y ,'f,c  SN  ' T HAVP  A - I N CQCKT  rp  IT  •/ 

call  0 e tr  s:  i t t r ^ , ccm r cl  > *. 

/•rcTsE  -vrli  I E V - S THF  S T r p AGF  ENTRIES  »HICH  CONTAIN  THE  GIVEN 
NEy.  THEY  A-c  PUT  IN  PFTPTSS  ANr  14  I $ IS  THE  NUMBER  CF  SUCH 

stlf  ace.pntt  res  «/ 

K < s K K H r Ve  r H_  K?  Y.N AM  £ ; 

TEST .LFng  Th : 

I FI  KO  = LcNGTH(  LOGICAL)  ) THEN 
re  Tn  «=x  I T ; 

S Yf-'.PCL*  SUMS  Tc  ILCCICal.KK  f 1 ) ; 
r r { SYMrw'l  -*  * C ' ) THEN 
re  Tfj  ; 

S YM 0CL  * S».:a  S TR  ( L cr- 1 C A L . KK  ♦ l f l ) ; 

[C( SYva^L  = ) T HE N 

re  TC  »'0T; 

SIC,v=  • c ' R ; 

l T5vsVia;ST?  ILTG  ICAL  ,<<_•  \ J^FN  C Lu  - K c Y - ^ A M_EJj 

(<KsXK»LFNG  r H £ Y.N  A M f ♦ l j" 

CCMiriuE: 

Cali  Chpcn.fck.kpy ( I T c v , s I GN  J ; 

/•»  CHEC.N_F:^.KFY  Takes  E Vc  p Y NCN-VJLL  OCINTFP  IN  R F T 15  T R S A\0  CHECKS 
IF  T >E  CCRJC  SP'^N'C  EN  T STOP  AGF.ENTP  Y has  ThE  NAME  INCICATEC  R Y ITEM 

THk.  IT  CHF'-K?  Jf  thf  SIGN  IS  Crap  EC  T.  IF  NCT THE  PH  I N Te°  IS_SET_TC_ 

NLLL.  C ThtF  w I S=  L=>'  U*  CHANGED’  *7 
GC  TP  TP.ST.L  eNGTH  ; 

NUT:  S I G\» ' l ' ° ; 

I TEM*SUPSTC ILpc ICAL ,kk  ¥?  ,IFNCTF.kCY_N£VP) ; 

KKr/KH  f *“,TH^<F  Y.NAHF  f 2 ; 

r.c  rn  c~Nrt‘UF: 

PR:  ' Call  Vc3cr’;  " ' •' 

/ * ■-'  c * C - CH-.CKS  Ic  NPN-NtJLl  PCINTCOS  IN  P E T r T 0 S APF  IN  wr  p < AP  P A Y • 

ip  t.  ,r  tmcy  arp  Appro  in  The  cpof'y  i\  vhich  thpy  appear  in  retptrs 

OTHERWISE  \r  TH | NC  HAPPENS  */ 

K K = K k » L ; 

_ r.c  T 0 c,r  T.s  iVf;  

"EXIT:  CALL  HCRGE;'  ~ ‘ 

M jvw; 

/•  nERt  Tm£  CMUfCMT  CF  wc»KAPPAY  IS  PUT  IN  OFTPr^S  ANO  M SET  TO  •/ 
Up  KK*l  TO  ** 'R  ; 

OPTPf&SfKK  )2WCrtYA0°AY (KV  | ; 

t NT  ; 

F H K F wr*RK.  A»>  4Y  ; * “ ' ’ 


I 116 
i 118 
l 119 
1 .121 
l 122 


i 126 
_1_  126 
l 127 


130 

131 
131 

131 

132 

132 

133 


113 

134 

136 

136 


1 36 

136 

137 
137 
137 

137 

138 

138 

139 

140 
14  1 

142 

143 

144 

14  5 

146 

147 

148 

149 

149 
15C 

150 
150 
150 

150 

151 

152 

153 

154 

155 

156 
156 
156 
156 

15  ? 
158 
ISO 
160 
160 
161 
162 


— 

— 

— 

-- 

• 

1 

2-  7 

8 

) 

9 

10 

' — 

14 

15 

16  , 

18 

19' 

V2  - 

13 

— 

20 

X T 


W V.*  * V 


RO'SSiH 


PRfJCEP'J9  F<KFY,OATAST): 

ic"  IRfr^IPVP  STU-*Cc  e\'T9Y)  PPTOIFVCS  ALL  TfF  STORAGE 

t|TH  A Kc  V AAYC  MKcy„  ANC  ttjx  I ( Laft’l  CAT  A-hCATAST*,« 

ST"***  tmc*j  T H1-  AUXIllIAPY  QaTa  IS  M3 1 CHECKED. 

[e*S  JP^P^E  STO*«rE_  F*rft  1=5  ul7F  "KFym  a->£  plaCFC  IN  AN 
PCV\rc?S  r'3  SIP  to  S'*“’v,h  III  ' THF  M i v b f p.  cp  pointers  IS  "Mm  •/ 
rr.t  DATA  ST  CHAO  ( * ) ; 
rCL  key  Chap (length _ k 0 y _ \ a y 6 ) ? 

DCL  LEN  FlXrC  RINAKY;  ’ 
rCl  A,i  rt_p  t3  PrT\r~9; 

CCL_SCA'IST  tM3Y|P:i»-jc5|  OPTIONS  (PCTNTF0); 

CCl  ta  tastp  ‘chap  < w VV_l  eng  tf'Jla  r a$  tq  1 based  { CaTa^ptr 7; * 
rci  NULL  eUl  L r IN; 


2 16* 
2 16* 


CH*=CX  Dl  0 c T : 

F DIP  ECTOFY^PTSc^NLLt  THEN 

nq  ; 

s t '“o  aV.TIp  rT^TT$"r~  1 n.lTstT 

Lf N*l£ NGTM (ua t as  n ; 

IP  LFN=0  then 
f)r  : 


dd  >m 1 1. E i s r^c  Arc_PTo--NuLi ) ; 

CALL  r T ^ 5 r T o T u q T 

ST^9A(iC-PTPaSCAN<!ISTCOACF-Pr0): 


E_NC_: 

CLSE~ 

do; 

nc  fcHTL  r ( STCE  ACE,rTR-.*NUU  )J 

OATA.PTOsGAT A^PT ; 

IP  f AT  jS  rrSl:°STo  fCA  T ASTQ  » I fLEN)  THFN 

_ CALL  -\t_pctdtos; 

STCLAGp.0  T-  =SC  AN<TI S rCFAGE.PTP I ; 


7 186 

7 Itt  7 


END: 

£ NO; 

OEM.kETpTkS:  P3CC; 



ir  M > F ~ ”*  J ( F r T T 0 S »”i  I TfFnT’uL  S Y Nr  0 ” l ' * a x «cTPIEV4LS  EXCEEDED  • 
r L$  c tfC  TPT5S  (H)sSTr>«AG£.PTP  J 
EMj  HN  7_*f  s : 

OOtC'.Gl^eT:  °P'C£C'J0E; 

/•  THIS  PP.CCO'IPL  L^^S  FC?  «K-*  Y_\ a*ph  [\  r^t  OIPECTCTY  anO 

_ _S  E T S ! 9 -C  T PJ^  T I f / 

O I if'  Tpoy_p  T-*S  T A o T~;  " 

H ! I 6 ( - ( ( D IF  EC  r :oY_3T9*MJLl  ) I ( K t Y_N  AVK*K  £ Y|  ) ) ; 

IF  <EY_NAVF>«rFY  THEN 
n fP f CTCP Y^PTP sCCWN^PTR j 
ELSE 

CI^EC  [Of  YJ^P  =G?_9  P ; 

EVP; 

cmc,  rucr*niocT. 


Step  5 


3 j o 7 Step  2 
3 1^8 

3 19Q 

3 190  of  RETRIEVE 


S 702 

5 202 

A 203 


•*  , 


426 


0 SC AN ST  : 

/•  SAMfc  A 


LMEh  C. 


PROCEru«c  c st_ptp.  ipe turns*  pointer)  : 

S pro  STCRaGE  »/ 

OCL  INO  E(XEO  8 f N A P Y. ; 

or  I. ..  ( S T_p  T P , P ) PC  INTER; 

S TCR  TR  = S T_pTR  ,* 

I NO*  l ; ’ "*  „„  

00  WHJL E (NAMF ( INC ) -*KEY ) ; 

_ I NT  = I NO ♦ l ; 

END ; 

K r_PT.RU  yrj  x 

^ETURaTp  ) ; 

cNO  SC  ANST  ; _ • p 

CNn  PET°  f E ; / 

pa^C  -CUP  C ; _ 

cl  I (iL.rv)  pixec  binary; 

^0  Ll«l  TC  »: 

1 P °ETPTkS (ll )-.*NUll  THEN 

00; ........ 

NN*  l ; 

00  WH ( L? U NN<=MP ) C (WCPK APP AY(NN) -*PETPTRS (LL ) I ) 
\n*\n*  I ; 

fN-n ; 


IF  \N>HH  then 

pn  • 

wr,R<APPAY(NN)  = PETPTPS(LL)J 
END  ; 


3 

3 

3 

3 

3 

A 

V 

V 

_ 3 
3 
3 
2 
2 
2 

3 

A 

5 

5 

; 6 

6 
* 
6 
7 
7 
7 
7 


<u  ** 

205 

206 
206 

..207  . 
2C9 

209 

210 
211 
212 
213. 
2 l A 

215 

216 

217 

218 
. 219 

220 

221 

222 

.223 

22V 

225 

226 

227 

228 

229 

230 


Step  12 


of  RETRIEVE 


>t  f .<_r 


END; 

e*'i>  'fHPr,p  ; 

_ N r Y : 

PF-^CzCU’  f<  U Jie.L'NARY  t : 


76 

3 

2 

2 

2 


72m 

232 

233 
23V 
23V 


COL  TTTLf  CHAP (L ENG T H.KF Y_\ A V ? ) ; 

3CL  'IN  Aj  Y 3 T T ( l ) ; * 2 236 

CCL  ( L L « \'N  ) FlxEC  °I*'APY;  2 237 

m Ll  *1  rr  v • 3 239 

IF  P?lDTf5(Lll-*MLL  THC\  V 239 

O'n;  ~ 5 2 VO 

STnRAOF.»TR*P=TPTPS(LL »;  5 2VI 

NN* 1 ; 5 2V2 

^0  (N'N<*«KFYS)C(NA^E(NN)-*TtTLSn;  6 2V3 

ANsNNHl;  6 2 V V 

E N C *.  6 2V5 

IF  f(fN<*  *K*r~YS  1 t ( LNa’PY* ''f*  > I)  |"(  ( TN>/»<2  YS  )C  (On~A~KV-  ’”6  2*6 

• C • b J 1 Then  6 2V6 

’f T°TPS (LL » -NLLl  ; 6 2V7 

f NO  .*  _ 5 2VR 

c N 0 ; “ “ 3 ?'*9 

END  CHFr k_EOR_«EY  ; 2 250 

" ENO'fiE  f'RdVE ; ~ ' l 251 


|JL  *&&£**■  V. 

— - - - -■ — _ 


^ t 


PRC  CSSS  I 'MAC  °n  ST,  TO  cp  fNasrroc  • ) J 
src  rg:  PtiOCSni/XFtSTR  INC  , TA  T A.PTc  > ; 

/•  THIS  PfOCEUHJE  TAKES  A $T51\o  rP  CCE-C  A T EN  a T F C KEY  \AMFS  IN  "STQlNC 

A. N't  A PSINTFft  T/?  AUXILLTAPY  I'ATa  ("CATa_PTK")  ANC  STCOf$  THE  TwO  IN 

A y t Y(*u  Y S(,_ACrV  ca'ch’lE^T"!>Y  >F  “wV*  Ich  IS  C A L L E C A "S  T HR  AGP  .6N  T p Y"  . 

c ACM  KEY  NAMP  l ►!  " S T 3 I N C M IS  P M E c f C IN  A 
"C  I K EC  Tc  »J  Y„Er  T-  Y " » THE  Cl°CCTCPY  hflvlNC  A "CKANCH  ANC  QQU*'0" 

S TF  UC  TU*  E • •/  

nci  S To,  INO  CHAO  ( • ) ; 

CCL_I)AT  A_DTP  PCIN  TEP  : 

ilNCLUGE  I.NClTscrSFnip')  ; 

DCL  n,J)  EtXEH  PINAPY; 

:CL  ( 0, LAST. S T.rNTPY.o TO J PCIKTCH; 

LCL  C 1 J?  o e N'T  _ AM  c CF  4P  (LEE  GTh^kEY.AA^E  ) ; 

CCL  f*:n  Frxpn  RfvAPY; 

ocl  » n i y en  Fixer  ?!m  pxt; 

CCL  sr-v/r  PriNfcP  f X T s c % A t : 

CCL  SCA'lST  EE'TA  Y (CHAP  ( LENCTH.KrY.NAPE  ) , PC  INTcP  I FETUPNS  (0GINTE 


nCL  CHCCX.n  l c _ ? T F'  TPY  tr>  *P  I IFM‘TF_<PY-.N  > ) RETURNS  (PCIkTFR) 


CCL  C F Nfc  "■  a T F_E*!  T FY  £s  T?y  (CHAP  ( L C N C * H_K  ? Y_  K A*-*  E I ) P 6 T^PN  S ( PC  ! E:  T F 


CCL  nijil  quilt  in 


N*lfvc.th<  stp  Inc,  )/LcNf.  TH_K6Y.NAPF; 
allCtatf  stop  age_  cr  tc  y ; “ 

LNST.Sr_FNTOY.PToZSTno_ACC^£r«»f 

[.ai  a_pt“cat a.oT’  ; 

C?  WH(Le f 7<*  **  r Y s J ; 

. C>IP°  E VT_NA«P  = SUP  S Tf  ( s T P I Nf  f J . L ENCTH.K  FY_NAMP  j 

ST»;p  agfIe nto  r .aA'*e  i r ) *ciHMi7.  t_aapf  ; ” 

STGP  AT*.F.r  N TO  Y #\F  X r_r  TP  rMJLL  ; 

I c S T c 5 T*NUL  l _ THf  V _ 

CP ; 

STAOTar.F»!Eo  ATF^CNT-’ YtC'JPPFNT.E.A^E  ) ; 

CALL  FSTAFLISHI  I NK  S I CUP  P EN  '.M  E , S r A«  T ) 


0 * C H EC  K _ 0 l a _ 3 "M  C l,o  ^ S i\  T _ n a V e 1 ; 

/«  P IS  NQ’.v  Thc  Pop  TP0  T r t£c  OIPGCTCFY  EM9Y  CF  thF  COPREN 
KEY  NAPE  («C«ioo  pnT.NAMF”  I •/ 

CALI  FSTAEL  I SHI  INKS(CLP?eNT^NAME ,?)  ; 


JSJ  +L FNGTm_kEY-namf 
PE'O; 


l 

18 

L 

l<? 

l 

20 

1 

2! 

l 

22 

2 

25 

2 

26 

2 

27 

2 

29 

3 

. 2<? 

R 

30 

R 

31 

<i 

32 

<• 

33 

®«.,c  cnue  i (K  rv  )Pf  TURN'S  ( °C  TN  Tf  0 I I 

_ST  CrTS  Tmc  *>=y  Af.n  STARTS  SEAPCHfN.3  THE  HIRFCT0oY. 

7s  IN  Tuf^Oif  vC  TOP  Y,.  T PFTl.PNS  THE  PCIMCP  TC 

y~  f ,\  T 3 Y • fp  f.rr,  if  ffNPPATES  A Nfc%  Entpy  in  THF  PPOPFR 
^A:.*LlSHrS  ThF  ‘.INKS  IN  the  niRPCTCPY,  PETUPNINO  THF 
Mr  \FNl  Y CM  t A-T  F 0 ENTRY.  * / 

CL  <EY  rw».\ki  (t  g»«c  Th^k  cy_i\ANE  ) ; 

cl  (NA*'.p_pTa *c » pcff. re«; 

I ai' Cjn~  Y ,p  TPs  s r A r Y ; 

IP  KC > >KF Y_N AMF  THEN 


IF  'JP_Prft-\ULL  THEN 
. . DC;  


Csf'!PFCTPCY_PTP  ; 

Ni'iC_Pr^rfN  fPATE.FNTPY(KEYl; 

OioCc  Tr»v.pTo*c; 

•ii’umo  *'Ethc<;  is  u src  fcp  t fe  cipectcry  */ 

'"'IocCTP‘Wv_oTx~>C1^FCTC'Y_c'JTjY#,Jd-Pto=NAmF_PTo 


y<kfy_na*>f  then 


IF  CCWN_P TP -NLll  THEN 


c IO  C(frr  JY_orc  ; 

rp*cr .vc*p  a tf.fvt-^y/vey); 
LIPcCT-'T,  y_ptm=c; 

r IV  EC  Tf  PY_?TR->C  JPFCTCPY.ENTO  Y .(VJUN 


om 

rl p p C rc° Y_p  IV  *CCVN_PTR 
CO  TC  TEST; 


\£VP  ; I.r.  Cl3CCTCOy  ENTRY  FCIjNC  */ 
MA^E_PTParHPFCTC°Y_PTR; 
fcNO  J 

pr  TlPN|NA«F_PTO  | ; 

Put)  CM'Ck  "or  k~’ $ f ; 


430 


' .'S>~ 


0 E N fc  F AT  fc.ENTPV : 

apUCEOUPF  (TITLE  |CETU°NS(  °riMFP)  : 

/•THIS  ?^0Ccr»*ir=  ALLOCATES  A NFw  hp  I ofC  Ttpy.^Mq  y"  FCP  THE  KEY  NAME  IN 
"T  HU"*  IMT  HU 2?S  ThE  'P  ? a,  T F F S IV  IT  Tf  NULL  A N C l NCP  5Mf N T$  THE 

CCON  T_t  F \uM*Jcs  Cc  ^I^fCTroy  entcjes  ( H » n I R EN  MJ  • / 

*>CL  T I TL?  CHAE  (tEVGTh^KEY.KAME) 

ALU-CATT  0 IK  ECT^fc  y^ea  try  ; 

KPY.'iAMr  rTiTLc ; 

UP.'’  TP  ,0CWN_PT  U f E (PST^  IN.L  I ST  »MJLl  5 

Y 1 ( r ? M * Y P I P £ f ( ♦ l ; 

peTtf>*',(niPCCr'!jRY_:,Tq); 

6no“gfmfpate_eVt5y;  * 

E$T AbLlShL  INKS: 

panrpf,(^p(  kcv,01P_®TO)  : 

/•(.$  TAdl  l SHUV^  .■>CPCC,U°6  AGCS  Tj-r  NEWLY  CP  E A T E C "STne  AGE.ENTR  Y " 

WITH  T-b  KEY  VAVC  CUEPENTLY  IN  "KEY"  T P the  L i Me  6 D LIST  IN  WHICH  THE 
C-  KcY  IS  Y?>inn»,-£T.,  f H c PH  ST  4 T n F A T £ £\TPY  IN  THE  LIST  * I Th  TmE 
CUEPk;.r  key  NAV F 'lS  PCMMED  TC'jY*  ThE  CUS^EM  key  NAME'S  OIPECTOPY 
fc-M&Y  . 

THE  POINTS*  TO  THE  CT^ECTCPY  EMPY  IS  TIR.PTK"*/ 

CCL  < FY  CHA'-  (LFfsGTF_Krv_NAMC|  ; 

TCL  (DIP.PTy  ,APcrv.|"pc  CNTcR; 

r prf  TO?  y^prffw^c^p  TH  * 

' [' r ' f i ? s f_  V 'V^il  s r *M. i t thfv 
r r- st.it^l i stslast^st  fnt®y  FTP; 

ELSE 
Dp; 


SIppap.p^dtp  *F  rp  sr.  IN_L  1ST; 

Ar>r W-SCi*  S r(  *"r  Y fs  rc  PiCc.Pro  l ; 

DC  *h  f i.  c ( a°e  ru-»s f. utL) ; 

S TP  5 AGE  _ P T P * A P 3 C W ; 

A°F  CH  = CCANS_JJ  XE  Y , ST_C°  AGE.PTp  ) ; 

7*  s riw’iV£.P7«  T » aYl  s 'a«eqv.‘ 

cf;n ; 

NEYT.PTC  (lHO-LAST.ST.ENTPY.PTP; 
e\»P  ; 

STTY3\r,r.OTP*LAST.ST.F\TPY.CTO; 

/«  E r S - T »/p3»r|._f»T3H  TV  »*L  A S T.S  TP  a AGF_f  ^ ; o Y " SINCE  IT  WAS  M^OIcIrP 

DY  SCAN  ST  »/ 

5*'P  -“STADLfSHLINKS; 

SC  A?  ST  : oor.r  erno  r(  T I TL  E , S T.PTP  )P  crur-.VS  | pf  I?  T?Q  I ; 

/•scanst  scans  a rrrpjr.6  f\t*  y u*  t/l  rrvr  s the  <£y  given  py  ‘title**/ 

/•IT  acri;^\S  Tr-c  VALUE  CE  7K  ppjnTEP  ASSOCIATED  WITH  that  k£y  •/ 

_C r L T I,T L ' CJ-  A c?  ( I F \| G T h_< E y_n  A V ? j ; 

DC L G T_e  TE  ~PC  I NT  FO  ; " * 

S TD* AC^.P  TP  = S T_DTP  ; 

Ino* t ; 

PTl  WMILEC  ( I\D<=  «kF  vs  ) S (NAME  ( I NT  I -- T T T L E M ; 

I VO*  I NPh  l ; 

END; 

" P*Nf  / T.  j TP  ( f.YCI  ; " ~ 

f.fnpLlP);  _ 

E.N’O  SONS  T; 

F no  STUPE: 


03 

94 

<>5 

06 

07 

98 

98 

99 
100 
101 
102 
102 
IC2 

103 
[O'* 
1 0 A 

104 

105 

106 

107 

108 
100 


-w.  :JL 


Sum:  PRCClX,  I.L.hl  returnsipic  •ssssqss'jsss1  i ; 

DCL X_L*J  J 1 t ' 933999  9 1 I 

DCL  ( I, L.H ) El XEO  8 IN  ; 

U_TE M P F t X E 0 PECt L ) STATIC  INITIO)  ; 

OCL  FIRST  SUM  SITU)  STATIC  INITI'l'S); 

F FIRST  SUM  THEN  

OC; 

F I R ST  SUM= 'O' B; 

T EMP=  0 ; 


C r i S I • « *'C ® n , c x t 5 p r , a i 2,7’,  l_)_*  \f  UN  P * f l c • ) ; 

ijnhkfliV:  r*®(;ciNf  <‘r.[Moexl: 

/•  c<TCKf  -L  rp  unpack*' 

/•  this  ;-wC‘r>uPc  r.  r ►•.  f k a i f s r.cne  fc»  unpacking  fifios. 

/*  ThF^e  -j  fasts  of  nrF*=ST: 

/•  ^sussr & i PTS (N 5To  i * c 

/•  «sLK)SCc  fprs(».srp.  > * i 

/•  ' *SU*SC0  ! p r S C -s  T p ) % 2 

CCl  \cXT_lNCCX  HIN  C|XEP(15|;  /«  THIS  PAPAVfTgQ  t=lLS  US  WHICH 

/•  IS  l HE  \EX7_ir:ctx  TC  USE  IN  a 

/*  rc-iccp  ro  fcp  su^scp ipr inc. 


fiCL 

fMeC'iJ"1 

f Cm  A® ( 3 ? 1 VAR  c 

xr  ; 

CCL 

*»  a u C S T - 

ivr,  CHA3CUI  V A O 

FXT 

CCL 

PL  I STk 

CHA-  ( 320 ) VA«  ; 

CCL 

SUn  SC  ^ l 

3r_ST&I\r,  ENTRY 

p F T i: 

CCL 

'.sri-  m 

' c I X F C ( IS)  EXT  ; 

CC  L 

k'P  rLINYCM*. 

CCL 

AY  SC  HP 

f *•  T - v ( Cm  Ac  I * ) ) ; 

CCL 

FTF  PfP 

PiO  1 N T cr‘  F X 7 ; 

'LCl  lE'  _c  if  T_csjr?v  F IT^:  cs;_CICT_6NTc.y-22; 

XCLL  <iA.L.NA*'r  FUEO;  aa_L_n AWF*  1C  I 

.'CCL  L r,..-r*'_KF  y_na- c Ffxcr;  Pf:C  rn_<F  v_x  ahf=  1C ; 

•I.  CLUi'c  I'iCUr  *»(FTF  i ; 

fXL  PUiH  5 T k r *:  i ;•  v ( m in  rixfctis)); 

CCl  FLPSI  K c T * v • 

i'CL  i«<n  l r ■;  r - y ( f h Vc  i «Tv  ac  7Ch*  ap  (*•)); 

CCl  KC/Xuc?.  C^rt'YCPfN  c;TtTf[«||  P £Tcc*'<  (CbJf  ( ?it  ; 

DC  L Plf.TMWr  -‘T  = vi?I.\  Flx-0(15)»  c E T UP  N 5 ( CH  AP  ( I C ) V AP  » ; 

CCL  chpthl:  FvT>  1 (Chao  t • J J F = turns  I CH  a = { 32  ) VA»); 

DCL  sYlc.CAIC  -■•T-y(M,i  c IXr  ~ ( l ^ , CUA«‘  ( 1 ) f P IN  FIXFC(15)I; 
_?T-  -f  T-_*»Te  ; 

masc-  jptsu  sra’i  * c 

TmF\  cr; 

C4;L  CFHPaATC^wr.vF.  INSTPS  : 

3 c T UP  N ; _ " 

g N C ; 

_j lj>  c _i p f stinsco  IP TS (N S_T£  J * I 

THEN  OH; 

CML  p«jShs  r k ( Nf  x r_  i \f  g x ) ; 

°L  LSTP*,r»n  • l| 

IVOxCHM  SFXT.INCEXJ  II 
• = l Tn  • II 

P I CHIRM  SUP  S CP  IPT  I T P I J |J 

’ I ; r . 

CALI  wF0Ll(i»HST5f*PLirxM; 

CALL  CF^P-ATt^HCVF. IVSTPS i 
mi  IST° * • C 4C  « * S 


>•  mi+SM •>-* 
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c f.  Fji  A T f: . v - _J_15  T r'  5_: ? 0 r r ; , 

• ! *TEr*NAL  r.  ^ PAC<’_C  ! FLO. 

• This  PPCCEOJ3*  r.Cf-E?AT:$  INSPECTIONS  TC; 

» r-'4*.SFFp  i n'hov^  r jcn  : 

- advance  The  OIJFPCJ  PCINTES  (T). 

:l  »dr  r = S *■  f v r t XFCt  l « / ; 

l F.  J A MJTYf  jS  ( MS  TP  | a « : • 

rr;*i  |C  C'5LC.LC'._T¥PF  (NST^)--'F'  /•  FIXEO  LENGTH  «/ 

Them  re ; 

PtiST«a»PFCNAK6  | | 

• . • It  _ . . 

c H°  T&  L e (*J  AvC  (MST5  ) ) II 

SUaSCc  1 PT.—S  T p.LN.C. . Li 

• = s'.^F  TP<  • II 

-F^CSTf  ING  I l_  _ 

'♦I*'  II 

PICR/°E('*lA-L£\Grh(NSTPM  I!  _ . 


Algorithm 

GEN -MOVE- INSTR-FOR- 


UN  PACKING 


| 


Call  ^:nLL(PLlST:','3Ll‘-t'); 

° L i ^ r 3 = • I - I ♦ • II 

P tc  TUP  C < -J  ! N_L  FNGr  h<  NS  r?  ) I II 

call  v*p CT i pTTTt 3 f • M L'l fT M : 

OC  r,jO  ; 

fttO; 

E L S = DO;  /•  C h a ^ fi  C T E°  - Va°IAPLE  LENGTH  •/ 
PI  l r T p S • r A 1 1 ' II 

r h p r q l e (lfa_pq c cj nst* i i i i 

♦ • * - 

CALL  WPPL L (PL  ISTP  , • PL  1 EX • ) : 

PL  1ST3 -»°FCNA^c  | | 

' II 

Cm»TCl*»  ( \ *«  t ( \ STh  ) ) II 
SU2Src IP T_ STRING  If 
'=SLPSTo(*  || 

* PPCS  TP  INC  II 
',!»LEN.'  II 
CHOrPLP(AAHffNSTQ))  |) 

• ) : ' ; 

_C  A L L * P ? L l I o L l $ T \_9  • p L l E ) ; 

P *L  1 F T 3 = ' t * I ♦ L ? N • ' II 

CHPTCLP I\A.*'E (NSTP M II 

CALL  v»ppl  UPL  iST^  t»  PLIEX'  ) *. 

oE  tupn ; 

6 NO; 


[ W 


AD-A032  630 


UNCLASSIFIED 
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76-05 


NL 


END 


DATE 

FILMED 
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CcS>  c • m *cpn » 
<r,*r:  rr;C( 

L LEN.OICTJ: 

L 

L l C':OT*_<?v 
rxrsKhlt  TO 
THIS  PRrCFCU 
LAllS  UNPACK 
THERE  ARE  3 


\sx  r_  Kitx 

•\  5 T*  r i \ PI 


LCL 

I'uxot'S 

CCl 

PlC  T*.iRc 

n cl 

--3li  : 

CCL 

PUahS  Tn 

CCL 

y«_'js  tk 

CCl 

c hr  r - c ■* 

pcl 

SYSE  Ph 

CCL 

•■v 

I 

j 

» • 
A. 

<InClU^'  1. 

FXT»F.F,SM«f  2,7?,  I » ,N«UN?KG«P#)  J ' 

Nr  X T_  ( FOE  X I WFCliPSIVF; 

Nfoy  fixco;  *«Lc.\.rir  t.6Mpy*J2; 

Fixem  ».vax_l_\ahf*  1C: 

_ \ v: F . f I x F_nj_ _? l^FV.C  IH^K  f V _N  A M E » 1 C J 

U*  p ir<. 

r-»F  GEMMATES  Thp  CCCE  pSCL’IREC  FCR  A GROUP » ANO 
▼P*  CEN^AT?  CrCF  FQR  ITS  HFHPEPS. 

CASES  OF  INTEREST:  _ _ ....  

»SU9’SC3!pTSCN$Ml  * C 

*SU«S#“©f  t>T?  (NJTffJ  » l 

*SUaSCP  iptsimstaT  * 2 
3INriXFC(l5)S_  _ . . 

XEOI 15)  EXT; 

him  f ixsof  is i ; _ ... 

« IN  c I x CO ( 15  ) ; 

.1.42*1 y.A_«  ; 

Y ( H I M F l X 6 C C l s n ; 

•’VCHIN  rixFOUSII  OCTUFNSCCHA0I1I  IS 
RY(MM  F!xCr(l5M  R S R°  N S ( CH  A Q ( 1C  ) VAR  I : 

I CHIP  I *|  VAI?  f CHAR  < • ))  ; 

RY(H|M  c IXf 0(  15  M ; 

* v ( c ha  « (•  rr v - njT\  c (cham  y?7  v apY* 

YlCM/.0|«|  ) ; 

-N  t r r f x t : 

‘ft  I FTP);  


Algorithm 

UNPACKCRP 


•/ 

•/ 

•/ 

*/  

V 

_•/ 

•/ 


lccal.a^itv  «in  Mxcoim; 

KLli  I - l J2C[__VAJ  ; 

l* PAC*  ENTRY (HIM  FtXECCiSn; 
INuxOtN  tvroY(MN  riycn<ISM  ocrc'F 
F I C T'JR  c ?N  TRY  (HIM  FIXCr(l5M  R S TL‘° 
3L  l £vtav|  Chap  ( *i  va«?  ,Cha9  < • ) | ; _ 
pushgt*  ru  try  him  c:xro<mi; 

»c0SfK  fN*»V; 

0 HR  T » L •*  FM9V(CHA»(  •!  I O-TLjeMtChA 

SYSEPh  sr  T1YICM/.D  |«)  ) ; _ 

hth.pIi-  p-unttr  f x T : 

: cl Ju:  l XL  i ftftl  FTP  ) • 

3 TF *F Tk.P  rc  ; 

I f ’ * Si  J IS  C a fPTSO'ST  p .L  .* C 

TmcK  hC? 

L 1CAL_A° I TY»AF ITYINST5  ) 8 
DC  f*  I Tn  LrC  AL  AR  T ry  ; 


evc; 
r ftijkr  ; 
rwo: 

FLSc  a *s<mcK  iptmastm  * i 

then  nn; 

'C'.LL  P ' j S w S T K ( K F x T — [ N C c X ) ; 

°I.  i s tf  *»o^  • II 

P CXGEMf.CxT.INCEx)  I I 
* * l Tn  • || 

PfCTtoF ( SUbf-CV  IPT2INSTR ))  II 


Call  wPPLI<PIIST*,»PLI?X')S 

pl isr«s #00.  • i f 

!N0xrc\«(Nf  XT_!NCEX)  \ 1 

•Vi  *'jn  c x I < f M 
__  CMPTPL^  (NAKf  (\STff  ) | || 


_ CALL  WPPL1 IPL1STP, «Pt  1FX*  )J 

L'1CAI.P^!TY*APITYCNSTS1? 

noj«_ijn  lccal^apity; 

C/flll  "unpack  (>;F  XT. INCEXtl) ; 

5*:n;  _ 

PL  ISTP-'CNCs • ; 

CUL  V»PrL  1 I PL l $ TP  * • PL  IEX  • Is 

kptupk; 

fmc; 


IF  «SIJL«SCP  IPTSCKSTP  ) a 2 

TMtr:  on: 

CALL  Pt!SbSlK(KF.XT_i\ceY)  f 
PL  1STP* 'CALL  • II 

CHPT3LS ( :X  ! 5T.FFCC (K$TP  > ! 


• • - 

CUL  Wt.->Ll  «PL1ST»  ,'PLIFX*  I 
= L l<UP».o()  . | | 

If  OXCtVfiFXT.INCex) 
• » 1 T <■  ? .<  1 < I . • II 

1 1 

■ 

CH®TFLa (NAvf  CnSIP ) | 
• • • • 

1 1 

CALI.  V PP|  l ( Pl  IS  rt  , • cl  LEX*  ) ; 
lOCA|.A5rTY*AP»Tv(s$ra>; 
ti o 1 = 1 K*  i rc  al  _ a®  i ty  ; 

CAI  l IJKPACXfNEXT.jNCfXMl  5 

? MO; 

_pi_1ST3*  *c\c : • :_ 

"CALL  Vpsl’i  I'PLIS  fpf  *cl  I5x*  I : 
call  pf:PS tk ; 

^CTijwm; 
k v0: 


SLSF  /*  *S'J*SCX  FPTSt*Sfo  > ISF*T  C C°  l f®  2.  •/ 

CM  L S y $ E 9 ® | •f.PNInCn  - UfcP<C*P:  ILLEGAL  fcSUH  SC  5 I P r S : 

°Jr  Ti;PE  I «5(JFSr  “ JPT$  (NSTo  ))  || 

• Fn*  Sljii  $TF  CCTLP  6 •••  II 

WA“?r^si3jLJI 

• •»’»)  J " — — 

/*  »JNPACK.0KDIJP  •/ 


^ 'iir.  a*.  ■*  j 
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•rrccessi  2.  iz.  i » .f^woccL1 1 ; 

•iIBCL!  R«CLILEVSLjtSTe  |rt|i 

! • r V i s rl'cccpurf  wOrrs  cur  the  ceclaRa r ics  in  • 

• level*  > a.*u  weakinc  u»\sT* i.ng’  .if  necessary  rr 
NUlURLe  CaRCS*/ 

CCL  »rp  ;r:c  Ch\»I*i  var: _• 

CCl  levsl  F [red  OEC  : 

CCl, LEVEL. STR  INC-,  CHAR  Ml ; 

/«  LEVEl.STA  IMP.  is  ThF  sr»INi  CXRRFSSICN  CF  the' 

CCl  ai.Af.KS  CHIP  (711  STATIC  IN  1 T.<  \ I ; _ 

CCL  IKCENT-  CMA®  I 71)  VAR; 

CCL  l »Ll_LlN«  STATIC,  

2 C*.  Char  < U IN  IT  ( • • I , 

’ t t a t char (Tti . 

_2~XL,IVnP  char  I 31  I N I T ( *OCL  * ) • 

i CCL?  Air  ,g<j<joo,  pHTICI:  ...  

IF  lE  Ve  L>0  THEN 


STPING* 
FIT  On 


»UT  srRfflC.ILEVEL.ETR  INC)  *CIT:l:vEU(F(3)); 

ST?  I%C«LCVFl_ST»  | ■•;<-,  jj  ■ • I I ?TR  InC; 

INC; 

CCIP«CCL*  * l! 

IF  L S V C L * 0 Thc  n IMPEST."; 

ELSE  l.s3sir.S'l‘:STR  | ELA^KS  , l.LcVELI: 
l * L r V fc L » L = N'.TM(ST7[NCJ  ; 

pc  vh  I l c 1 1 >711  ; 

JO  1*71  TP  I »Y  -l 

AH  ILE  I INDFxP  I )•  ,S'J5STR(  jTR  I.SG,  I,  in* 

SnO  : 

IF  1*03  THEM  ._  . . 

OC ; 

/.* C a \ r.  e IMP  : s p a < 3 C 1ST  : CC'i  LI \ l£_c clumv. 

I * 7i : in"En  f»  * • : 

LEVEL «o  • ..  . 

I MO  r 

. /*FPUMP  ,e?.EA*  >C  INT_. AT  I • /.  


TEXT*  |»"«M  I | SLe>T«  1ST*  INC  , l , I »; 
<F!TE  FILilPLtCCLI  5 JP  • I »L  1_U  SE  I I 
0CL**'.CLA*1  ; 

ST? i*i';rS""f t?  (st?  I*;.:, i *i> : 

VEL  » LE'-.TmISTR  INC  I : 


TEXT  » I f.  OEM  T I ISTRINC: 

WA  l 1 1 FlLElRLlOCL)  RRCMRLl.LINEI  r 
HE  TURN! 

END: 


•P2LCESSI  •f.r5T.M4CRn.S'*»l2, 72, 1 ) ,N»WPBl  1*  I ; 

V.5PLI:  PPICISTb  ING.riLFI  ; 

-/*  this  rcut-c:f  is  «e$PCNsme  ecs  writing  cfi»f*mo  »i  i statements  «/ 

/*  TC  VARIOUS  TEmPU  ROPY  F I L E S_. «/ 

-/»  INPUTS  ARE:  ' ' •/ 

/•  SITING  - the  OL1  TARGE!  STPINr;  «/ 

/•  FILE  -~iAM=  OF  TEE  <?*s’S7*'SO  cUTPIJT  *F  1 1 E " i/ 

-/«  Each  CALL  OF  worn  WRITES  CNF  Ca  MC’=  C“»CS  CF  ELI  COOS.  IF  ♦/ 

7*  STRING  IS  LC-IG"  Than  7i  Chap  AC  Icss.  IREN  TWC  CR  MORE  Carcs  ARE  */ 

/ - WRITTE.i.  SVJCC  ESS  I vf  CA»OS  ARE  strung  TOGETHER,  COLU“N  7?  3EINO  •/ 

/«  C JNSICE1  cr>  AOJACcNT  IC  CCLLhn  2 CF  The  next  carc.  •/ 

EACH  GeUfRATCO  CA^C  HAS_  2 JECLENCE  FIFLCS:  •/ 

/*  CaiTlV  -CL'LS"  T?- 76  - TELLING  CN  which  CALL  TC  WRPLITHISC  ABO  ~ »/ 

/*  HAS  r.FFEBATEIl;  THIS  MjHeSP  is  THE  SAVE  FCc  ALL  CABrjS  »/ 

/•  gene  rated  in  t he  sa‘*f  call  cf  w“pli.  •/ 

/*  CARo»  - COLS  77-30  - TELLING  The  ABSClUrE  r?OER  IN  WHICH  THIS  •/ 

/•  CA=n  «AS  CREATED,  •/ 

-/•  The  SMRY  OrCL  ah  at  ICN  Fca  wfpli  IS:  •/ 

" /«  ” 'x£~Wc6Tf  ENTFVtCHAF’lif  ViSRY'lNG.CHARlin:  " " ~*7 


-CLL  ST  < 1 i,  G CnAr.  <r|  V A.  EYING; 

cci  file  ''haf  i ■) ; 

ccl  ihsp  Chari*-)  varying  ctl; 

CLL  IPlILa.PH-’O.PLIPRCC)  FILS  CI.TPUT  RFCCPC  SFCl; 

_OCL  l XITR'C  ST’.TiCj 

2 “ «l'.TciiIC.'t|T=?l'  Cha/i  l ) "iNITl'i  •), 

2 TsvT  Cha-171), 

Z CALL*  INIT(C), 

2 CAaO*  r ic  • OSOG  • IM1ICI; 

- lALL* *L all v * l : 

A »Lt.*iGIH(STR  | HG  ) ; 

ALLOCATE'  T = mp;  ‘ ‘ * 

IcaP>STP  I*,*,;  /.  THIS  S I '"jl  A T ES  call-py-vall-f  •/ 

00  •.hilE(lF-:GTm|TF*.0)>?i  I ; 

00  1=71  TO  1 DY  -1  wh  IL  F I I«'CE,  ( » ; , (J»  • .StBSTRITEHP,  I , t ) )«0)  ; 
END: 

[F  1=0  The;;  /»  rt»H  F [*jg_  EREAKFC  IAT  , CCA  7 [AUF  COL.  2_  •/  _ 

1 = fl : 

/•  R'ihih  RREak-phint  AT  I »/ 

T *-  X I * SUE  STTI  TEMP, 1,1); 

CALL  HHT: 

T E = SIW  s TR 1 temp  , 1 • i ) ; 

_e*VO: 

imt«Tehp; 

CALL  WRT; 

FE ) E TEAP; 

-«RT:  Ph'iC; 

CiEO«*C.A*n»» i : 

_ I h r:tc_.  1 PL  l e * • TOEI.  y r i f c ciLEirLUX)  each  ( CGT’>  HC ) ; 

ELSE  !=  fTlE’  = '"L  10*."'  T hen  i Tc  FILMPLICM  H "Om  ( C’J  Tp  EC)  ; 

ELSE  IF  FILE  * 'silTnC1  TH£V  VEIT-  F I L E I PL  IPRCf.  I 

FFCH  (CUTE  EC  ) ; 

ELS=  /«  fivALIO  FILE  parameter  •/ 


